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(54) INFORMATION PROCESSING SYSTEM AND METHOD 



(57) An information processing system and method 
are disclosed in which information processing is per- 
formed in a highly efficient manner using an enabling 
key block ( EKB) on the basis of a tree structu re including 
category subtrees. A key tree is formed so as to include 
a plurality of subtrees serving as category trees catego- 
rized in accordance with categories and managed by 
category entities. An EKB including data produced by 



selecting a path in a tree and encrypting a higher-level 
key in the selected path using a lower-level key in the 
selected path. The resultant EKB is provided to a device. 
Distribution of EKB's is managed on the basis of an EKB 
type definition list representing the correspondence be- 
tween an EKB type identifier and one or more identifi- 
cation data identifying one or more category trees that 
can process an EKB of an EKB type specified by the 
EKB type identifier. 
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Description 

Technical Field 

[0001 ] The present invention relates to an information 5 
processing system, an information processing method, 
an information processing apparatus . and an informa- 
tion storage medium and a program storage medium, 
and particularly to a data distribution system and meth- 
od for providing various kinds of data such as content 
data to an authorized user by means of a process in- 
cluding a cryptographic process. More particularly, the 
present invention relates to an information processing 
system, an information processing method, an informa- 
tion processing apparatus, and an information storage 
medium and a program storage medium, in which a key 
block is produced using a hierarchical-tree key distribu- 
tion technique depending on a device to which a content 
is to be provided, and the key block is used in encryption 
of the content and also in transmission of a content key, 
thereby ensuring that the content, the content key, and 
other data are securely provided. 

Background Art 

[0002] It is now very popular to distribute various kind 
of software data such as a game program, audio data, 
and image data (hereinafter, such data will be referred 
to as a content) via a network such as the Internet or via 
a distributable storage medium such as a DVD or a CD. 
After loading such content data onto a PC (Personal 
Computer) or a game machine of a user via data trans- 
mission, or after loading a storage medium on which 
content data is stored onto the PC or the game machine, 
the user can enjoy played back content. A content 
stored on a storage medium may be stored into a stor- 
age device such as a memory card or a hard disk dis- 
posed in a PC or a recording/playing-back apparatus so 
that the content can be reproduced from the storage de- 
vice. 

[0003] An information apparatus such as a video 
game machine or a PC may include an interface for re- 
ceiving a content via a network or accessing a DVD or 
a CD, and further include a RAM, a ROM, or the like, 
used as a memory area for storing control means, a pro- 
gram, and data needed to reproduce a content. 
[0004] Various kinds of contents such as music data, 
video data, or a program, may be read from a storage 
medium and played back on an information apparatus 
itself such as a game machine or a PC used as a play- 
back device or played back on a display or by a speaker 
connected to the information apparatus, in response to 
a command input by a user directly to the information 
apparatus or indirectly via input means connected to the 
information apparatus. 

[0005] In general, the right of distribution of software 
contents such as a game program, music data, or video 
data is held by producers or sellers or the software con- 



tents. Software contents are generally distributed under 
specific usage limitation to secure that only authorized 
users can use software contents and that unauthorized 
copies thereof cannot be made. 

[0006] One technique of limiting usage to specific us- 
ers is to encrypt a content. More specifically, a content 
such as audio data, video data, or a game program is 
distributed via the Internet or the like after encrypting 
the content, and a decryption key, which is means for 
decrypting the encrypted content, is given only to au- 
thorized users. 

[0007] The encrypted data can be converted into its 
original form (plaintext) by performing a predetermined 
decryption process upon the encrypted data. The tech- 
nique of encrypting and decrypting information using an 
encryption key and a decryption key is well known in the 
art. 

[0008] Various techniques of encrypting and decrypt- 
ing data using an encryption key and a decryption key 
are known. One of them is a technique known as com- 
mon key cryptography. In the common key cryptogra- 
phy, the same key called a common key is used as both 
an encryption key for encrypting data and a decryption 
key for decrypting the encrypted data, and the common 
key is given only to authorized users so that unauthor- 
ized users who do not have the common key cannot ac- 
cess the data. A specific example of the common key 
cryptography is that based on the DES (Data Encryption 
Standard). 

[0009] An encryption key for encrypting dataand a de- 
cryption key for decrypting the encrypted data can be 
obtained from a password or the like using a unidirec- 
tional function such as a hash function. Herein, the uni- 
directional function refers to a function whose input is 
very difficult to guess from an output thereof. Although 
an encryption/decryption key can be generated using an 
output obtained by applying a unidirectional function to, 
for example, a password determined by a user, it is sub- 
stantially impossible to determine, from the obtained en- 
cryption/decryption key, the password that is original da- 
ta from which the encryption/decryption key is generat- 
ed. 

[0010] Another known technique is public key cryp- 
tography in which an encryption key used for encryption 
and a decryption key used for decryption are generated 
in accordance with different algorithms. In the public key 
cryptography, a public key, which is allowed to be used 
by any unspecified user, is issued by a particular user, 
and a document to be provided to that particular user is 
encrypted using the public key issued by the particular 
user. The document encrypted using the public key can 
only be decrypted using a secret key corresponding to 
the encryption key used to encrypt that document. The 
secret key is held only by the user who issued the public 
key, and thus the document encrypted using the public 
key can be decrypted only by the user having the secret 
key. A representative example of the public key cryptog- 
raphy is that based on the RSA (Rivest-Shamir-Adel- 



15 



20 



25 



30 



35 



40 



45 



50 



2 



3 



EP 1 253 738 A1 



4 



man) algorithm. Using one of above-described cryptog- 
raphy techniques, it is possible to realize a system in 
which encrypted contents can be decrypted only by au- 
thorized users. 

[001 1 ] In such a content distribution system , encrypt- s 
ed contents are provided to users via a network or via 
a storage such as a DVD or a CD, and content keys 
used to decrypt the encrypted contents are provided on- 
ly to authorized users. To prevent a content key from 
being copied in an unauthorized manner, it has been 
proposed to encrypt a content key and provide the en- 
crypted content key to an authorized user so that only 
the authorized user can decrypt the encrypted content 
key using a decryption key held only by the authorized 
user. 

[001 2] A judgment of whether one is an authorized us- 
er or not is generally made by performing authentication 
between a user device and a content provider who is a 
sender of a content, before transmitting a content or a 
content key. In a usual authentication process, if the us- 
er is determined to be an authorized one, a session key 
is produced which can be used only during the present 
communication, and data such as a content or a content 
key is transmitted after encrypting it using the session 
key. Authentication may be performed using the com- 
mon key cryptography or the public key cryptography. 
In the case where authentication is performed using the 
common key cryptography, a common key for system- 
wide use is needed. This results in inconvenience in re- 
newal. On the other hand, in the case where the public 
key cryptography is employed, undesirably complex cal- 
culations using a memory with an undesirably high ca- 
pacity are required. 

Disclosure of Invention 

[0013] It is an object of the present invention to pro- 
vide a technique of securely transmitting data only to 
authorized users without having to perform mutual au- 
thentication between a sender and a receiver, by using 
an encrypted key block which can be used (decrypted) 
in a plurality of category trees defined as subtrees in a 
hierarchical key distribution tree. 

[0014] More specifically, it is an object of the present 
invention to provide an information processing system, 
an information processing method, an information 
processing apparatus, an information storage medium, 
and a program storage medium, in which an enabling 
key block (EKB) including encrypted key data which can 
be decrypted by one or more selected category trees is 
produced thereby making it possible for devices belong- 
ing to any one of the selected category trees to use the 
enabling key block (EKB), and an EKB type definition 
list, indicating which EKB type can be processed or de- 
crypted by which category tree, is used thereby making 
it possible to perform production and management of 
enabling key blocks (EKB's) in a highly efficient manner. 
[001 5] According to a first aspect of the present inven- 



tion, there is provided an information processing system 
in which a key tree is formed so as to include leaves, a 
root, and nodes existing in paths from the respective 
leaves to the root, wherein a plurality of devices are as- 
signed to respective leaves and keys are assigned to 
the root, the leaves, and the nodes, respectively; and 
an enabling key block (EKB) is provided to a device, 
wherein the enabling key block (EKB) includes data pro- 
duced by selecting a path in the key tree and encrypting 
an upper-level key in the selected path using a lower- 
level key in the selected path such that the encrypted 
data can be decrypted only by the device which can use 
a node key set corresponding to the selected path, 

wherein the key tree includes a plurality of sub- 
trees serving as category trees that are grouped in ac- 
cordance with categories and managed by category en- 
tities; and 

the enabling key block (EKB) is produced by a key 
distribution center (KDC) such that an EKB type defini- 
tion list representing the correspondence between an 
EKB type identifier and one or more category tree iden- 
tification data each identifying a category tree that can 
process an EKB of an EKB type identified by the EKB 
type identifier is held in the key distribution center 
(KDC) , one or more category tree identification data cor- 
responding to an EKB type identifier included In an EKB 
request are extracted from the EKB type definition list, 
and an EKB is produced which can be decrypted in com- 
mon in the one or more category trees identified by the 
extracted one or more category tree identification data. 
[0016] In an embodiment of the information process- 
ing system according to the present invention, in the 
EKB type definition list, the identification data identifying 
a category tree that can process an EKB is a node ID 
identifying a node in the category tree. 
[0017] In an embodiment of the information process- 
ing system according to the present invention the EKB 
type definition list includes a description of a device be- 
longing to a category tree. 

[0018] In an embodiment of the information process- 
ing system according to the present invention, the EKB 
type definition list can by held or accessed by an EKB 
requester that requests the key distribution center 
(KDC) to produce an EKB; and the EKB requester se- 
lects an EKB type identifier on the basis of the EKB type 
definition list and outputs an EKB production request in- 
cluding the selected EKB type identifier to the key dis- 
tribution center (KDC). 

[0019] In an embodiment of the information process- 
ing system according to the present invention, the cat- 
egory entity produces a sub enabling key block 
(sub-EKB) serving as an EKB that can be processed on 
the basis of one or more keys assigned to nodes or 
leaves in a category tree managed by the category en- 
tity; and on the basis of one or more sub-EKB's pro- 
duced by one or more category entities corresponding 
to one or more category tree identification data selected 
on the basis of the EKB type definition list, the key dis- 
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tribution center (KDC) produces an EKB that can be 
processed in common in one or category trees defined 
in the EKB type definition lists. 

[0020] In an embodiment of the information process- 
ing system according to the present invention, the key 5 
tree includes a rool tree having a multilevel tree struc- 
ture at the top, atop-level category tree directly connect- 
ed to the root tree, and a sub-category tree located at a 
level below the top-level category tree and connected 
to the top-leve! category tree; the category entity serves 10 
as a manager entity of the top-level category tree and 
manages the top-level category tree and the sub-cate- 
gory tree located below the top level category tree and 
connected to the top level category tree; the category 
entity produces a sub enabling key bock (sub-EKB) is 
serving as an EKB that can be processed on the basis 
of one or more keys assigned to nodes or leaves in the 
top-level category tree and sub-category tree, located 
below the top-level category tree and connected to the 
top-level category tree, which are managed by the cat- 20 
egory entity; and on the basis of one or more sub-EKB's 
produced by one or more category entities correspond- . 
ing to one or more category tree identification data se- 
lected on the basis of the EKB type definition list, the 
key distribution center (KDC) produces an EKB that can 25 
be processed in common in one or category trees de- 
fined in the EKB type definition lists. 
[0021] In an embodiment of the information process- 
ing system according to the present invention, the key 
distribution center (KDC) performs registration of a new 30 
EKB type identifier in the EKB type definition list, if and 
only if approval of the registration is obtained from ail 
category entities managing one or more category trees 
selected as category trees that can process an EKB type 
to be registered. 35 
[0022] In an embodiment of the information process- 
ing system according to the present invention, the key 
distribution center (KDC) performs revocation of an EKB 
type identifier registered in the EKB type definition list, 
if and only if a revocation request is received from at 40 
least one of category entities managing one or more cat- 
egory trees selected as category trees that can process 
an EKB type to be revoked. 

[0023] In an embodiment of the information process- 
ing system according to the present invention, in re- 45 
sponse to an EKB type definition list request issued by 
an EKB requester or a category entity requesting the 
key distribution center (KDC) to produce an EKB, the 
key distribution Center (KDC) transmits a newest version 
of EKB type definition list to the requester of the list. so 
[0024] In an embodiment of the information process- 
ing system according to the present invention, the cat- 
egory entity sends information of a change in a category 
tree managed by the category entity to the key distribu- 
tion center (KDC); and in accordance with the tree 55 
change notification received from the category entity, 
the key distribution center (KDC) performs necessary 
renewal on the EKB type definition list and sends renew- 



al information to the EKB requester and the category 
entity. 

[0025] According to a second aspect of the present 
invention, there is provided an EKB distribution appara- 
tus serving to produce an EKB and being disposed in 
an information processing system in which a key tree is 
formed so as to include a subtree serving as a category 
tree categorized in accordance with a category, the cat- 
egory tree including leaves, a root, and nodes existing 
in paths from the respective leaves to the root, wherein 
a plurality of devices are assigned to respective leaves 
and keys are assigned to the root, the leaves, and the 
nodes, respectively; and an enabling key block (EKB) is 
provided to a device, wherein the enabling key block 
(EKB) includes data produced by selecting a path in the 
key tree and encrypting an upper-level key in the select- 
ed path using a lower-level key in the selected path such 
that the encrypted data can be decrypted only by the 
device which can use a node key set corresponding to 
the selected path, 

wherein the EKB distribution apparatus 
stores, in storage means , an EKB type definition 
list representing the correspondence between an EKB 
type identifier and one or more identification data iden- 
tifying one or more category trees that can process an 
EKB of an EKB type identified by the EKB type identifier; 
and 

upon receiving an EKB production request from 
an EKB requester extracts one or more category tree 
identification data corresponding to an EKB type identi- 
fier included in the EKB production request from the 
EKB type definition list, and produces an EKB that can 
be decrypted in common in one or more category trees 
identified by the one or more category tree identification 
data. 

[0026] According to a third aspect of the present in- 
vention, there is provided an EKB requesting apparatus 
serving as an EKB requester which issues an EKB pro- 
duction request and being disposed in an information 
processing system in which a key tree is formed so as 
to include a subtree serving as a category tree catego- 
rized in accordance with a category, the category tree 
including leaves, a root, and nodes existing in paths 
from the respective leaves to the root, wherein a plurality 
of devices are assigned to respective leaves and keys 
are assigned to the root, the leaves, and the nodes, re- 
spectively; and ah enabling key block (EKB) is provided 
to a device, wherein the enabling key block (EKB) in- 
cludes data produced by selecting a path in the key tree 
and encrypting an upper-level key in the selected path 
using a lower- level key in the selected path such that 
the encrypted data can be decrypted only by the device 
which can use a node key set corresponding to the se- 
lected path, 

wherein the EKB requesting apparatus 
stores, in storage means, an EKB type definition 
list representing the correspondence between an EKB 
type identifier and one or more identification data iden- 
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tifying one or more category trees that can process an 
EKB of an EKB type identified by the EKB type identifier; 
and 

produces EKB production request data including 
an EKB type identifier in the EKB type definition list and 
outputs the EKB issue request. 

[0027] According to a fourth aspect of the present in- 
vention, there is provided A category tree managing ap- 
paratus serving to manage a category tree and being 
disposed in an information processing system in which 
a key tree is formed so as to include a subtree serving 
as a category tree categorized in accordance with a cat- 
egory, the category tree including leaves, a root, and 
nodes existing in paths from the respective leaves to the 
root, wherein a plurality of devices are assigned to re- 
spective ieaves and keys are assigned to the root, the 
leaves, and the nodes, respectively; and an enabling 
key block (EKB) is provided to a device, wherein the en- 
abling key block (EKB) includes data produced by se- 
lecting a path in the key tree and encrypting an upper- 
level key in the selected path using a lower-level key in 
the selected path such that the encrypted data can be 
decrypted only by the device which can use a node key 
set corresponding to the selected path, 

wherein the category tree managing apparatus 
produces a sub enabling key block (sub-EKB) function- 
ing as an EKB that can be processed on the basis of a 
key assigned to a node or leaf belonging to a category 
tree managed by the category tree managing apparatus 
and outputs the resultant sub enabling key block 
(sub-EKB) to a key distribution center (KDC). 
[0028] According to a fifth aspect of the present inven- 
tion, there is provided an information storage medium 
having an EKB type definition list stored therein, the 
EKB type definition list being produced such that a key 
tree is formed so as to include a subtree serving as a 
category tree categorized in accordance with a catego- 
ry, the category tree including leaves, a root, and nodes 
existing in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to respective 
leaves and keys are assigned to the root, the leaves, 
and the nodes, respectively; an enabling key block 
(EKB) is produced so as to include data produced by 
selecting a path in the key tree and encrypting an upper- 
level key in the selected path using a lower-level key in 
the selected path so that the encrypted data can be de- 
crypted only by the device which can use a node key 
set corresponding to the selected path; and the EKB 
type definition list is produced so as to represent the cor- 
respondence between an EKB type identifier assigned 
to the enabling key block (EKB) and identification data 
identifying a category tree that can process an EKB of 
an EKB type identified by the EKB type identifier. 
[0029] In an embodiment of the information storage 
medium according to the present invention, in the EKB 
type definition list, the identification data identifying a 
category tree that can process an EKB is a node ID iden- 
tifying a node in the category tree. 



[0030] In an embodiment of the information storage 
medium according to the present invention, the EKB 
type definition list includes a description of a device be- 
longing to a category tree. 
5 [0031] According to a sixth aspect of the present in- 
vention, there is provided an information processing 
meLhod comprising: 

forming a key tree including a subtree serving as a 
10 category tree categorized in accordance with a cat- 
egory and managed by a category entity, said cat- 
egory tree including leaves, a root, and nodes ex- 
isting in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to re- 
15 spective leaves and keys are assigned to the root, 

the leaves, and the nodes, respectively; and provid- 
ing an enabling key block (EKB) to a device, where- 
in the enabling key block (EKB) includes data pro- 
duced by selecting a path in the key tree and en- 
20 crypting an upper-level key in the selected path us- 
ing a lower-level key in the selected path such that 
the encrypted data can be decrypted only by the de- 
vice which can use a node key set corresponding 
to the seiected path, 

25 

wherein the enabling key block (EKB) is produced 
by a key distribution center (KDC) such that an EKB type 
definition list representing the correspondence between 
an EKB type identifier and one or more category tree 
30 identification data each identifying a category tree that 
can process an EKB of an EKB type identified by the 
EKB type identifier is held in the key distribution center 
(KDC), one or more category tree identification data cor- 
responding to an EKB type identifier included in an EKB 
35 request are extracted from the EKB type definition list, 
and an EKB is produced which can be decrypted in com- 
mon in the one or more category trees Identified by the 
extracted one or more category tree identification data. 
[0032] In an embodiment of the information process- 
40 ing method according to the present invention, in the 
EKB type definition list, the identification data identifying 
a category tree that can process an EKB is a node ID 
identifying a node in the category tree. 
[0033] In an embodiment of the information process- 
es ing method according to the present invention, the EKB 
type definition list includes a description of a device be- 
longing to a category tree. 

[0034] In an embodiment of the information process- 
ing method according to the present invention, the EKB 

50 type definition list can by held or accessed by an EKB 
requester that requests the key distribution center 
(KDC) to produce an EKB; and the EKB requester se- 
lects an EKB type identifier on the basis of the EKB type 
definition list and outputs an EKB production request in- 

55 eluding the selected EKB type identifier to the key dis- 
tribution center (KDC). 

[0035] In an embodiment of the information process- 
ing method according to the present invention, the cat- 
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egory entity produces a sub enabling key block 
(sub-EKB) serving as an EKB that can be processed on 
the basis of one or more keys assigned to nodes or 
leaves in a category tree managed by the category en- 
tity; and on the basis of one or more sub-EKB's pro- 
duced by one or more category entities corresponding 
to one or more category tree identification data selected 
on the basis of the EKB type definition list, the key dis- 
tribution center (KDC) produces an EKB that can be 
processed in common in one or category trees defined 
in the EKB type definition iists. 

[0036] In an embodiment of the information process- 
ing method according to the present invention, the key 
tree includes a root tree having a multilevel tree struc- 
ture at the top, atop-level category tree directly connect- 
ed to the root tree, and a sub-category tree located at a 
level below the top-level category tree and connected 
to the top-level category tree; the category entity serves 
as a manager entity of the top-level category tree and 
manages the top-level category tree and the sub-cate- 
gory tree located below the top level category tree and 
connected to the top levef category tree; the category 
entity produces a sub enabling key bock (sub-EKB) 
serving as an EKB that can be processed on the basis 
of one or more keys assigned to nodes or leaves in the 
top-level category tree and sub-category tree, located 
below the top-level category tree and connected to the 
top-level category tree, which are managed by the cat- 
egory entity; and on the basis of one or more sub-EKB's 
produced by one or more category entities correspond- 
ing to one or more category tree identification data se- 
lected on the basis of the EKB type definition list, the 
key distribution center (KDC) produces an EKB that can 
be processed in common in one or category trees de- 
fined in the EKB type definition lists. 
[0037] In an embodiment of the information process- 
ing method according to the present invention, the key 
distribution center (KDC) performs registration of a new 
EKB type identifier in the EKB type definition list, if and 
only if approval of the registration is obtained from all 
category entities managing one or more category trees 
selected as category trees that can process an EKB type 
to be registered. 

[0038] In an embodiment of the information process- 
ing method according to the present invention, the key 
distribution center (KDC) performs revocation of an EKB 
type identifier registered in the EKB type definition list, 
if and only if a revocation request is received from at 
least one of category entities managing one or more cat- 
egory trees selected as category trees that can process 
an EKB type to be revoked. 

[0039] In an embodiment of the information process- 
ing method according to the present invention, in -re- 
sponse to an EKB type definition list request issued by 
an EKB requester or a category entity requesting the 
key distribution center (KDC) to produce an EKB, the 
key distribution center (KDC) transmits a newest version 
of EKB type definition list to the requester of the list. 



[0040] In an embodiment of the information process- 
ing method according to the present invention, the cat- 
egory entity sends information of a change in a category 
tree managed by the category entity to the key distribu- 

5 tion center (KDC); and in accordance with the tree 
change notification received from the category entity, 
the key distribution center (KDC) performs necessary 
renewal on the EKB type definition list and sends renew- 
al information to the EKB requester and the category 

10 entity. 

[0041] According to a seventh aspect of the present 
invention, there is provided a program storage medium 
having a computer program stored therein for causing 
a computer system to execute information processing 
15 jn an information processing system in which a key tree 
is formed so as to include a subtree serving as a cate- 
gory tree categorized in accordance with a category, the 
category tree including leaves, a root, and nodes exist- 
ing in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to respective 
leaves and keys are assigned to the root, the leaves, 
and the nodes, respectively; and an enabling key block 
(EKB) is provided to a device, wherein the enabling key 
block (EKB) includes data produced by selecting a path 
in the key tree and encrypting an upper-level key in the 
selected path using a lower- level key in the selected 
path such that the encrypted data can be decrypted only 
by the device which can use a node key set correspond- 
ing to the selected path , wherein the computer program 
30 comprising the steps of: 

on the basis of an EKB type identifier included in an 
EKB production request, extracting identification 
data identifying a category tree from an EKB type 

35 definition list representing the correspondence be- 
tween an EKB type identifier and one or more iden- 
tification data identifying one or more category trees 
that can process an EKB of an EKB type identified 
by the EKB type identifier; and 

40 producing an EKB that can be decrypted in common 
in one or more category trees identified by the ex- 
tracted identification data. 

[0042] In the present invention, by using the encrypt- 
45 ed key tree distribution technique based on the hierar- 
chical tree structure in which devices are assigned to 
leaves of an n-ary tree, a content key used as an en- 
cryption key of a content, an authentication key used in 
authentication, or a program code is transmitted togeth- 
50 er with an enabling key block. 

[0043] Furthermore, the data size of the enabling key 
block is reduced by employing a data format including 
an encrypted key data part and a tag part indicating the 
locations of encrypted keys, thereby making it possible 
55 to perform decryption easily and quickly. That is, data is 
produced in an encrypted form that can be decrypted 
only by an authorized device whereby the data is se- 
curely provided to the authorized device. 
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[0044] Furthermore, an enabling key block (EKB) is 
produced so as to include encrypted key data that can 
be decrypted in selected one or more category trees 
thereby making it possible for any device belonging to 
any one of those selected category trees to use the en- 5 
abling key block (EKB). The EKB is produced and man- 
aged in a highly efficient manner by using the EKB type 
definition list representing which EKB can be processed 
or decrypted in which category tree. 

[0045] A program storage medium according to the 10 
present invention is a medium which provides a compu- 
ter program in a computer- read able form to a general- 
purpose computer system executable of various pro- 
gram codes. The medium is not limited to a particular 
type, but various types of media, for example, a storage 15 
medium such as a CD, FD, or MD or a transmission me- 
dium such as a network may be employed. 
[0046] The program storage medium defines a coop- 
erative relationship in structure or function, for realizing 
a function of a particular computer program on a com- 20 
puter system, between the computer program and the 
storage medium. That is, by installing a particular com- 
puter program onto a computer system via a program 
storage medium, it becomes possible to achieve a co- 
operative operation on the computer system thereby 25 
achieving functions similarto those achieved by the oth- 
er aspects of the present invention. 
[0047] In the present invention, the term "system ,, is 
used to describe a logical collection of a plurality of de- 
vices, and it is not necessarily required thatthe plurality 30 
of devices are disposed in a single case. 
[0048] These and other objects and features of the 
present invention will become more apparent from the 
following detailed description of embodiments with ref- 
erence to the accompanying drawings. 35 

Brief Description of the Drawings 

[0049] 

40 

Fig. 1 is a diagram showing an example of an infor- 
mation processing system according to the present 
invention. 

Fig. 2 is a block diagram showing an example of a 
recording/reproducing apparatus used in the infor- 45 
mation processing system according to the present 
invention. 

Fig. 3 is a tree structure diagram showing various 
keys and a process of encrypting data used or per- 
formed in the information processing system ac- so 
cording to the present invention. 
Fig. 4 is a diagram showing an example of an ena- 
bling key block (EKB) used to distribute various 
keys and data in the information processing system 
according to the present invention. 55 
Fig. 5 is a diagram showing an example of a manner 
of distributing a content key using an enabling key 
block (EKB) and ah example of a decryption proc- 



ess, in the information processing system accord- 
ing to the present invention. 
Fig. 6 is a diagram showing an example of a format 
of an enabling key block (EKB) used in the informa- 
tion processing system according to the present in- 
vention. 

Fig. 7 is a diagram illustrating tags in an enabling 
key block (EKB) used in the information processing 
system according to the present invention. 
Fig. 8 is a diagram showing an example of a data 
format used to distribute an enabling key block 
(EKB) together with a content key and a content, in 
the processing system according to the present in- 
vention. 

Fig. 9 is a diagram showing an example of a process 
performed by a device in a case where an enabling 
key block (EKB) is distributed together with a con- 
tent key and a content, in the processing system 
according to the present invention. 
Fig. 10 is a diagram showing correspondence be- 
tween an enabling key block (EKB) and a content 
for a case in which an enabling key block (EKB) and 
contents are stored on a storage medium, in the in- 
formation processing system according to the 
present invention. 

Fig. 11 is diagram showing a process of distributing . 
a content using an enabling key block (EKB) in the 
information processing system according to the 
present invention, 

wherein, for the purpose of comparison, a process 
of distribution a content according to a conventional 
technique is also shown. 

Fig. 12 is a diagram showing an authentication se- 
quence using a common key cryptographic tech- 
nique, performed in the information processing sys- 
tem according to the present invention. 
Fig. 13 is a diagram showing (a first example of) a 
data format used to distribute an enabling key block 
(EKB) together with an authentication key and an 
example of a process performed by a device, in the 
information processing system according to the 
present invention. 

Fig. 14 is a diagram showing (a second example of) 
a data format used to' distribute an enabling key 
block (EKB) together with an authentication key and 
an example of a process performed by a device, in 
the information processing system according to the 
present invention. 

Fig. 15 is a diagram showing an authentication se- 
quence using a public key cryptographic technique, 
performed in the information processing system ac- 
cording to the present invention. 
Fig. 16 is a diagram showing a process of transmit- 
ting an enabling key block (EKB) together with a 
content key using authentication using a public key 
cryptographic technique, in the processing system 
according to the present invention. 
Fig. 1 7 is a diagram showing a process of transmit- 
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ting an enabling key block (EKB) together with an 
encrypted program data, in the processing system 
according to the present invention. 
Fig. 1 8 is a diagram showing an example of a proc- 
ess of producing an MAC value used to produce a s 
content integrity check value (ICV), in the informa- 
tion processing system according to the present in- 
vention. 

Fig. 19 is a diagram showing (a first example of) a 
data format used to transmit an enabling key block 10 
(EKB) together with an ICV generation key, in the 
information processing system according to the 
present invention. 

Fig. 20 is a diagram showing (a second example of) 
a data format used to transmit an en abling key block is 
(EKB) together with an ICV generation key, in the 
information processing system according to the 
present invention. 

Fig. 21 is a diagram showing a method of preventing 
data from being copied, by storing an integrity check 20 
value (ICV) in a medium, in the information process- 
ing system according to the present invention. 
Fig. 22 is a diagram showing a method of managing 
a content integrity check value (ICV) separately 
from a content storage medium, in the information 25 
processing system according to the present inven- 
tion. 

Fig. 23 is a diagram showing an example of cate- 
gorization using category subtrees in a hierarchical 
tree structure, in the information processing system 30 
according to the present invention. 
Fig. 24 is a diagram showing a process of producing 
a simplified enabling key block (EKB), in the infor- 
mation processing system according to the present 
invention. 35 
Fig. 25 is a diagram showing a process of producing 
an enabling key block (EKB), in the information 
processing system according to the present inven- 
tion. 

Fig. 26 is a diagram showing a (first example of) 40 
simplified enabling key block (EKB), used in the in- 
formation processing system according to the 
present invention. 

Fig. 27 is a diagram showing a (second example of) 
simplified enabling key block (EKB), used in the in- 
formation processing system according to the 
present invention. 

Fig. 28 is a diagram showing a manner of managing 
category trees in a hierarchical tree structure, in the 
information processing system according to the 50 
present invention. 

Fig. 29 is a diagram showing the detailed manner 
of managing category trees in a hierarchical tree 
structure, in the information processing system ac- 
cording to the present invention. 55 
Fig. 30 is a diagram showing a manner of managing 
category trees in a hierarchical tree structure, in the 
information processing system according to the 



present invention. 

Fig. 31 is a diagram showing a reserved node used 
in management category trees in a hierarchical tree 
structure, in the information processing system ac- 
cording to the present invention. 
Fig. 32 is a diagram showing a new category tree 
registration sequence in management of category 
trees in a hierarchical tree structure, in the informa- 
tion processing system according to the present in- 
vention. 

Fig. 33 is a diagram showing the relationship be- 
tween a new category tree and a higher-level cate- 
gory tree in management of category trees in a hi- 
erarchical tree structure, in the information process- 
ing system according to the present invention. 
Fig. 34 is a diagram showing a sub-EKB used in 
management of category trees having a hierarchi- 
cal tree structure, in the information processing sys- 
tem according to the present invention. 
Fig. 35 is a diagram showing a device revocation 
process performed in management of category 
trees having a hierarchical tree structure, in the in- 
formation processing system according to the 
present invention. 

Fig. 36 is a diagram showing a device revocation 
sequence performed in management of category 
trees having a hierarchical tree structure, in the in- 
formation processing system according to the 
present invention. 

Fig. 37 is a diagram showing a sub-EKB renewed 
in response to device revocation in management of 
category trees having a hierarchical tree structure, 
in the information processing system according to 
the present invention. 

Fig. 38 is a diagram showing a category tree revo- 
cation process performed in management of cate- 
gory trees in the form of a hierarchical tree structure, 
in the information processing system according to 
the present invention. 

Fig. 39 is a diagram showing a category tree revo- 
cation sequence performed in management of cat- 
egory trees in the form of a hierarchical tree struc- 
ture, in the information processing system accord- 
ing to the present invention. 

Fig. 40 is a diagram showing the relationship be- 
tween a revoked category tree and a higher-level 
category tree in management of category trees in 
the form of a hierarchical tree structure, in the infor- 
mation processing system according to the present 
invention. 

Fig. 41 is a diagram showing setting of capabilities 
in management of category trees in the form of a 
hierarchical tree structure, in the information 
processing system according to the present inven- 
tion. 

Fig. 42 is a diagram showing setting of capabilities 
in management of category trees in the form of a 
hierarchical tree structure, in the information 
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processing system according to the present inven- 
tion. 

Fig. 43 is a diagram showing a capability manage- 
ment table managed by a key distribution center 
(KDC) in the information processing system accord- 5 
ing to the present invention. 

Fig. 44 is a flow chart of a process of producing an 
EKB on the basis of a capability management table 
managed by a key distribution center (KDC) in the 
information processing system according to the 10 
present invention. 

Fig. 45 is a diagram showing a capability notification 
process performed when a new category tree is reg- 
istered, in the information processing system ac- 
cording to the present invention. 15 
Fig. 46 is a diagram showing a . category trees used 
in the information processing system according to 
the present invention. 

Fig. 47 is a diagram showing examples of process- 
es performed among an EKB requester, a key dis- 20 
tribution center, and a top-level category entity 
(TLCE), in the information processing system ac-. 
cording to the present invention. 
Fig. 48 is a diagram showing an example of hard- 
ware configurations of an EKB requester, a key dis- 25 
tribution center, and a top-level category entity 
(TLCE), in the information processing system ac- 
cording to the present invention. 
Fig. 49 is a diagram showing device node key (DNK) 
set held by a device in the information processing 30 
system according to the present invention. 
Fig. 50 is a diagram showing a data format of an 
EKB type definition list used in the information 
processing system according to the present inven- 
tion. 35 
Fig. 51 is a flow chart of an EKB type registration 
process performed in the information processing 
system according to the present invention. 
Fig. 52 is a flow chart of an EKB type revocation 
process performed in the information processing 
system according to the present invention. 
Fig. 53 is a flow chart of a tree change notification 
process, performed in the information processing 
system according to the present invention. 
Fig. 54 is a flow chart of an EKB type list requesting 45 
process performed in the information processing 
system according to the present invention. 
Fig. 55 is a diagram showing a sub-EKB production 
process performed in the information processing 
system according to the present invention. 50 
Fig. 56 is a diagram showing a sub-EKB production 
process performed in the information processing 
system according to the present invention. 
Fig. 57 is a diagram showing a process of producing 
an EKB by combining sub-EKB's in the information 55 
processing system according to the present inven- 
tion. 

Fig. 58 is a diagram showing a process of producing 



a sub-EKB in a situation in which there is a device 
to be revoked, in the information processing system 
according to the present invention. 
Fig. 59 is a diagram showing a process of producing 
an EKB by combining sub-EKB's in a situation in 
which there is a device to be revoked, in the infor- 
mation processing system according to the present 
invention. 

Fig. 60 is a diagram showing a data format of a com- 
bined EKB produced from sub-EKB's used in the 
information processing system according to the 
present invention. 

Fig. 61 is a diagram showing a data format of a com- 
bined EKB produced from sub-EKB's used in the 
information processing system according to the 
present invention. 

Fig. 62 is a diagram showing a data format of a com- 
bined EKB which is produced from sub-EKB's in a 
situation in which there is a device to be revoked, 
in the information processing system according to 
the present invention. 

Fig. 63 is a diagram showing a revocation process 
in data distribution system in the information 
processing system according to the present inven- 
tion. 

Fig. 64 is a diagram showing a revocation process 
in a recording system in the information processing 
system according to the present invention. 

Best Mode for Carrying Out the Invention 

[Outline of system] 

[0050] Fig. 1 illustrates an example of a content dis- 
tribution system based on an information processing 
system according to the present invention. A device on 
a content transmission side 1 0 transmit a content or a 
content key in an encrypted form to various devices on 
a content reception side 20. A device on the reception 
side 20 plays back video data or audio data or executes 
a program using the content or the content key acquired 
by decrypting the received encrypted content or en- 
crypted content key. Transmission of data between the 
content transmission side 10 and the content reception 
side 20 is performed via a network such as the Internet 
or via a distributable storage medium such as a DVD or 
a CD. 

[0051] Specific examples of transmission means 
used on the content transmission side 10 include the 
Internet 11, satellite broadcasting 12, a telephone line 
13, and a medium 14 such as a DVD or CD. Specific 
examples of devices on the content reception side 20 
include a personal computer (PC) 21, a portable com- 
puter (PD) 22, a portable device 23 such as a portable 
telephone or PDA (Personal Digital Assistants), a re- 
cord ing/playing-back apparatus 24 such as a DVD play- 
er or a CD player, and a playback device 25 such as a 
game terminal. The devices on the content reception 
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side 20 can acquire a content transmitted from the con- 
tent transmission side 10 via communication means 
such as a network or via a medium 30. 

[Device Configuration] 

[0052] Fig. 2 is a block diagram illustrating a configu- 
ration of a recording/reproducing apparatus 100 that is 
an example of devices on the content reception side 20 
shown in Fig. 1 . The recording/reproducing apparatus 
100 includes an input/output interface 120. an MPEG 
(Moving Picture Experts Group) codec 130, an input/ 
output interface 140 including an A/D and D/A converter 
141, cryptography means 150, a ROM (Read Only 
Memory) 160, a CPU (Central Processing Unit) 170, a 
memory 1 80, and a drive 1 90 for driving a storage me- 
dium 195, wherein these parts are connected to each 
other via a bus 110. 

[0053] The input/output interface 120 receives a dig- 
ital signal representing a content such as video data, 
audio data, or a program provided from the outside and 
outputs the received digital signal over the bus 1 1 0. The 
input/output interface 120 also receives a digital signal 
via the bus 110 and outputs the received digital signal 
to the outside. The MPEG codec 130 MPEG-decodes 
MPEG-coded data supplied viathe bus 110 and outputs 
the resultant decoded data to the input/output interface 
140. The MPEG coded 130 also MPEG-encodes a dig- 
ital signal supplied from the input/output interface 140 
and outputs the resultant encoded signal over the bus 
110. The input/output interface 140 includes the A/D and 
D/A converter 141. The input/output interface 140 re- 
ceives a content in the form of an analog signal from the 
outside and converts it into digital form using the A/D 
and D/A converter 141. The resultant digital signal is 
output to the MP EG codec 130. Conversely, if the input/ 
output interface 140 receives a digital signal from the 
MPEG codec 130, the input/output interface 140 con- 
verts it into analog form using the A/D and D/A converter 
141 and outputs the resultant analog signal to the out- 
side. 

[0054] The cryptography means 1 50 is formed of, for 
example, a one-chip LSI (Large Scale Integrated Cir- 
cuit) so as to serve to encrypt/decrypt and a digital con- 
tent signal supplied via the bus 110 and also serve to 
perform authentication. The resultant encrypted/de- 
crypted data is output over the bus 110. The cryptogra- 
phy means 150 may be realized not only using a one- 
chip LSI but may also be realized by software or a com- 
bination of software and hardware. A specific manner of 
forming the cryptography means 1 50 using software will 
be described later. . 

[0055] The ROM 1 60 stores program data used by the 
recording/reproducing apparatus. The CPU 170 con- 
trols various parts such as the MPEG codec 130 and 
the cryptography means 150 by executing the program 
stored in the ROM 160 or the memory 180. The memory 
180 may be realized using, for example, a nonvolatile" 



memory so as to serve to store the program executed 
by the CPU 1 70 or data used by the CPU 170. Key sets 
used in the encryption/decryption process performed by 
the device are also stored in the memory 180. The key 

5 sets will be described later. The drive 1 90 reads (repro- 
duces) digital data from the storage medium 1 95 by driv- 
ing the storage medium 1 95 capable of storing and re- 
producing digital data, and the drive 190 outputs the 
read digital data over the 1 1 0. Conversely, if digital data 

10 js received via the bus 11 0 : the drive 190 supplies the 
received data to the storage medium 1 95 so that the dig- 
ital data is stored onto the storage medium 195. 
[0056] The storage medium 1 95 is a medium capable 
of storing digital data, and specific examples thereof in- 

15 elude an optical disk such as a DVD or a CD, a magne- 
tooptical disk, a magnetic disk, a magnetic tape, or a 
semiconductor memory such as a RAM. In the present 
embodiment, the storage medium 1 95 is assumed to be 
removably mounted on the drive 1 90, although the stor- 

20 age medium 1 95 may be disposed in a fixed fashion in 
the recording/reproducing apparatus 100. 
[0057] The cryptography means 150 shown in Fig. 2 
may be realized using a one-chip LSI or using software 
or a combination of software and hardware. 

25 

[Distribution keys on the basis of a tree structure] 

[0058] A manner of assigning an encryption key to 
each device and a manner of distribution data are de- 

30 scribed below for a case in which encrypted data is 
transmitted from a device on the transmission side 10 
to a device on the reception side 20 shown in Fig. 1. 
[0059] In Fig. 3, numbers from 0 to 15 at the bottom 
denote respective devices on the content reception side 

35 20. That is, leaves in the hierarchical tree structure 
shown in Fig. 3 denote respective devices. 
[0060] When devices 0 to 1 5 are produced or shipped, 
or at a proper time thereafter, a key set including a leaf 
key assigned to a leaf corresponding to a device and 

40 also including node keys assigned to respective nodes 
present in a path from that leaf to the root in the hierar- 
chical tree structure shown in Fig. 3 is stored in each 
device. K0000 to K1111 shown at the bottom of Fig. 3 
denote leaf keys assigned to the respective devices 0 

45 to 15, and KRto K111 at levels from the top to the second 
level as counted from the bottom denote node keys. 
[0061] In the tree structure shown in Fig. 3, for exam- 
ple, a device 0 has a leaf key K0000 and node keys 
K000, K00, K0, and KR. Similarly, a device 5 has K0101, 

50 K010, K01, K0, and KR, and a device 15 has K1 111, 
K1 1 1 , K1 1 K1 , and KR. Although in the specific example 
shown in Fig. 3, the tree includes only sixteen devices 
0 to 15 and the tree has a symmetric four-level structure, 
the tree may include a greater number of devices and 

55 may have a different number of levels other than 4. 
[0062] Each device in the tree structure shown in Fig. 
3 may be of various types which may use various types 
of storage media such as a storage device fixedly dis- 
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posed in a device or a removable storage medium such 
as a DVD, a CD, an MD, or a flash memory. Further- 
more, various types of application services may be pro- 
vided via this tree structure. That is, the hierarchal tree 
structure for use in distribution of contents or content s 
keys, such as that shown in Fig. 3, is formed so as to 
adapt to such various types devices and various types 
applications. 

[0063] In a system including such various types of de- 
vices and various types of applications, parts thereof are 
properly grouped. For example, in Fig. 3, a part en- 
closed by a dotted line is set as one group including de- 
vices 0, 1,2, and 3, which use the same type of storage 
medium . For the devices included in this group enclosed 
by the dotted line, a common content in an encrypted 
form may be transmitted at the same time from a pro- 
vider, or a content key that can be used by all devices 
in the group may be transmitted. Each device in the 
group transmits content payment data in an encrypted 
form to a provider or a clearance institution. When con- 
tent providers or institutions such as a clearance insti- 
tution transmit data to devices, they may transmit data 
at the same time to all devices 0, 1 , 2, and 3 in the group 
enclosed by the dotted line in Fig. 3. The tree shown in 
Fig. 3 may include a plurality of such groups. Content 
providers or institutions such as a clearance institution, 
which transmit and receive data to and from devices, 
function as message data distribution means. 
[0064] All node keys and leaf keys may be managed 
in a unified fashion by one key management center, or 
node keys and leaf keys may be managed on a group- 
by-group basis by message data distribution means 
such as providers or clearance institutions that transmit 
and receive data to and from the respective groups. In 
a case where secrecy of a key is broken, node keys and 
leaf keys are renewed by the key management center, 
the providers, or the clearance institutions. 
[0065] In the present tree structure, as can be seen 
from Fig. 3, all three devices 0, 1 , 2, and 3 included in 
one group have common node keys K00, K0, and KR. 
Use of such common node keys makes it possible to 
provide, for example, a common content key only to the 
devices 0,1,2, and 3. For example, if the node key K0O 
that are held by all devices 0,1,2, and 3 is employed 
as a content key it is possible to provide the content key 
that can be used in common only by the devices 0,1,2, 
and 3, without necessitating an additional key transmis- 
sion process. If a content key Kcon is encrypted using 
the node key K00 and a value Enc(K00, Kcon) obtained 
as a result of encryption is distributed to the devices 0, 
1 , 2, and 3 via a network or a storage medium, then only 
the devices 0, 1,2, and 3 can acquire the content key 
Kcon by decrypting the encryption value Enc(K00, 
Kcon) using the node key K00 that are held in common 
by these devices. Herein, Enc(Ka, Kb) denotes datathat 
is obtained by encrypting Kb using Ka. 
[0066] At a some point of time t, if it turns out that keys 
K001 1 , K001 , K00, K0, and KR held by the device 3 have 



been analyzed by a hacker and secrecy of the key has 
been broken, it is needed to isolate the device 3 from 
the system to protect data transmitted or received in the 
system (group including the devices 0, 1 , 2, and 3). For 
this purpose, it is needed to change the node keysKOOl , 
K00, K0, and KR to new keys K(t)001, K(t)00, K(t)0, K 
(t)R and transmit the new keys to the devices 0, 1 , and 

2. Herein, K(t)aaa denotes a renewed key of generation 
of t obtained by renewing a key Kaaa. 

[0067] Distribution of renewed, keys is described be- 
low. Renewal of keys is achieved by supplying a table 
representing block data called an enabling key block 
(EKB) such as that shown in Fig. 4(A) to the devices 0, 

1 , and 2 via a network or a storage medium. The ena- 
bling key block (EKB) includes encrypted new keys to 
be distributed to devices corresponding to leaves in the 
tree structure shown in Fig. 3. The enabling key block 
(EKB) is also called a key renewal block (KRB). 
[0068] The enabling key block (EKB) shown in Fig. 4 
(A) includes block data that can be used for renewal of 
keys only by devices that need renewal of node keys, 
in the specific example shown in Fig. 4, the block data 
is produced for the purpose of distributing renewed node 
keys of generation of t to the devices 0,1, and 2 in the 
tree structure shown in Fig. 3. As can be seen from Fig. 

3, the devices 0 and 1 need K(t)00, K(t)0, and K(t)R as 
renewed node keys, and the device 2 needs K(t)001, K 
(t)00, K(t)0, and K(t)R as renewed node keys. 
[0069] As can be seen from Fig. 4(A), the EKB in- 
cludes a plurality of encrypted keys. An encrypted key 
Enc(K0010, K(t)001) described at the bottom is pro- 
duced by encrypting renewed node key K(t)001 by the 
leaf key K001 0 held by the device 2, and thus the device 
2 can acquire the renewed node key K(t)001 by decrypt- 
ing Enc(K0010, K(t)001) using the leaf key of the device 

2. Using this renewed node key K(t)001 obtained via de- 
cryption, an encrypted key Enc(K(t)001, K(t)00) in the 
second row as counted from the bottom in Fig. 4(A) can 
be decrypted into the renewed node key K(t)00. Simi- 
larly, an encrypted key Enc(K((t)00, K(t)0) in the second 
row as counted from the top in Fig. 4(A) can be decrypt- 
ed into the renewed node key K(t)0, and an encrypted 
key Enc(K(t)0, K(t)R) at the top in Fig. 4(A) can be de- 
crypted into K(t)R. On the other hand, for the devices 
KO0OO and K0001 , the node key K000 is not needed to 
renew, and thus only renewed keys K(t)00, K(t)0, and K 
(t)R are needed for the devices K0000 and K0001 . The 
devices K0000 and K0001 acquire K(t)00 by decrypting 
an encrypted key Enc(K0OO, K(t)00) at the third row as 
counted from the top in Fig. 4(A), and acquire the re- 
newed node key K(t)0 by decrypting the encrypted key 
Enc(K(t)00, K(t)0) at the second row as counted from 
the top in Fig. 4(A). Furthermore, K(t)R is acquired by 
decrypting the encrypted key Enc(K(t)0, K(t)R)atthetop 
in Fig. 4(A). In this way, the devices 0, 1 , and 2 can ac- 
quire the renewed key K(t)R. In Fig. 4(A), indexes indi- 
cate the absolute addresses of the node keys and leaf 
keys used as decryption keys. 
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[0070] In a case where the node keys K(t)0 and K(t) 
R in high levels of the tree structure shown in Fig. 3 are 
not needed to renew, but only the node key K00 is need- 
ed to renew, the enabling key block (EKB) may be 
formed such as shown in Fig. 4(B) whereby the renewed 5 
node key K(t)00 can be distributed to the devices 0, 1 , 
and 2. 

[0071] The EKB shown in Fig. 4(B) may be used to 
distribute a new content key to be used in common by 
a particular group. For example, it is assumed that the 10 
devices 0, 1 , 2, and 3 in the group enclosed by the dotted 
line in Fig. 3 use a particular type of storage media, and 
that a new common content key K(t)con is needed. In 
this case, the renewed content key K(t)con for use in 
common is encrypted using K(t)00 obtained by renew- 15 
ing the node key K00 used in common by the devices 
0, 1,2, and 3, and resultant encrypted data Enc(K(t), K 
(t)con) is distributed together with the EKB shown in Fig. 
4(B). This method of distribution allows data to be dis- 
tributed such that the distributed data cannot be decrypt- 20 
ed by the other devices such as a device 4. 
[0072] That is, the devices 0,1, and 2 can acquire the 
content key K(t)con that is valid at the point of time t by 
decrypting the encrypted data described above using K 
(t)00 that can be obtained by processing the EKB. 25 

[Distribution of Content Key using EKB] 

[0073] Fig. 5 illustrates a specific example of a proc- 
ess performed by the device 0 to obtain the content key so 
K(t)con which is valid at the point of time t from the data 
Enc(K(t)00, K(t)con), which has been produced by en- 
crypting the new common content key K(t)con using K 
(t)00 and supplied together with the EKB shown in Fig. 
4(B) to the device 0 via a storage medium. In this case, 35 
the content key K(t)con is message data encrypted by 
the EKB. 

[0074] As shown in Fig. 5, the device 0 produces the 
node key K(t)00 by processing the EKB of the genera- 
tion of t stored on the storage medium using the node 40 
key K000, which is already held by the device 0, in a 
similar manner as described above. Thereafter, the re- 
newed content key K(t)con is acquired by means of de- 
cryption using the renewed node key K(t)00. Further- 
more, the renewed content key K(t)con is encrypted us- 45 
ing the leaf key K0000 held only by the device 0 so that 
the content key K(t)con can be used at any time there- 
after. 

[Format of EKB] 

[0075] Fig. 6 shows an example of a format of an en- 
abling key block (EKB). A version 601 is an identifier 
indicating the version of the enabling key block (EKB). 
The version serves not only to identify the newest EKB 55 
but also to indicate the correspondence with contents. 
The depth indicates the number of layers of a hierarchi- 
cal tree of devices to which the enabling key block (EKB) 



is distributed. A data pointer 603 points to a location of 
data field in the enabling key block (EKB). A tag pointer 
604 points to a location of a tag field, and a signature 
pointer 605 points to a location of a signature. 
[0076] The data field 606 is used to store encrypted 
data such as a renewed node key. For example, data of 
encrypted keys associated with a renewed node key, 
such as that shown in Fig. 5, is stored in the data field. 
[0077] The tag field 607 is used to store tags indicat- 
ing the locations of the encrypted node keys and leaf 
key stored in the data field. The rule of determining the 
tags is described below with reference to Fig. 7. In a 
specific example shown in Fig. 7, the enabling key block 
(EKB) described above with reference to Fig. 4(A) is 
transmitted as the data. A table (b) in Fig. 7 shows the 
data that is transmitted in this specific example. Herein, 
the address of a top node in the encrypted keys is re- 
ferred to as a top node address. In this case, because 
a renewed root key K(t)R is included in the encrypted 
keys, the top node address becomes KR. The data Enc 
(K(t)0, K(t)R) at the top correspond to a location of the 
hierarchical tree shown in (a) of Fig. 7. The location in 
the hierarchical tree for the next data Enc(K(t)00, K(t)0) 
is lower left to the location of the previous data. When 
there is data, the tag is set to 0, while the tag is set to 1 
when there is no data. The tag is represented in the form 
of {L-tag, R-tag}, wherein L-tag denotes a left tag and 
R-tag denotes a right tag. In the case of the data Enc(K 
(t)0, K(t)R) in the top row, there is data to the left thereof, 
and thus the L-tag is set to 0, while the R-tag is set to 1 
because there is no data to the right thereof. Tags are 
set for all data in a similar manner. As a result, a se- 
quence of data and a sequence of tags are produced as 
shown in Fig. 7(c). 

[0078] The tags indicate the locations of data Enc . 
(Kxxx, Kyyy) in the tree structure. Key data Enc(Kxxx, 
Kyyy) stored in the data field is a simple sequence of 
encrypted keys, and thus the tags are used to indicate 
the locations, in the tree, of encrypted keys stored in the 
data field. Instead of using the tags, the locations in the 
tree may be represented by adding node indexes to the 
corresponding encrypted data, as described earlier with 
reference to Fig. 4. More specifically, the node indexes 
may be added as follows. 

0 : Enc(K(t) 0, K(t)root) 
00 : Enc(K(t) 00, K(t) 0) 
000 : Enc(K((t) 000, K(T) 00) 

and so on. However, use of the indexes results in redun- 
dancy in the data, a greater data size is needed to de- 
scribe the data, which is undesirable in transmission via 
a network. In contrast, if the tags are used as index data 
indicating the locations of keys, the locations of keys can 
be indicated by data with a smaller data size. 
[0079] Referring back to Fig. 6, the format of EKB is 
described further A signature is a digital signature writ- 
ten by a key management center, a content provider, or 
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a clearance institution, which has issued the enabling 
key block (EKB). When a device receives the EKB, the 
device verifies the signature to determine whether the 
received enabling key block (EKB) is a correct one is- 
sued by an authorized enabling key block (EKB) issuer. 

[Distribution of a content key and a content using an 
EKB] 

[0080] In the example described above, only the con- 
tent key is transmitted together with the EKB. A content 
encrypted using a content key may also be transmitted 
together with a content key encrypted using a content 
key encryption key and the content key encryption key 
encrypted using an EKB, as described below. 
[0081] Fig. 8 shows a data format used for the present 
purpose. In the data format shown in Fig. 8(a), Enc 
(Kcon, content) 801 denotes data produced by encrypt- 
ing the content using the content key (kcon). Enc(KEK, 
Kcon) B02 is data produced by encrypting the content 
key (Kcon) using the content key encryption key (KEK). 
Enc(EKB, KEK) 803 denotes data produced by encrypt- 
ing the content key encryption key KEK using the ena- 
bling key block (EKB). 

[0082] Herein, the node key (K000, K00,...) shown in 
Fig. 3 or the root key (KR) may be employed as the con- 
tent key encryption key KEK, or a key encrypted using 
the node key (K000, K00,...) or the root key (KR) may 
be employed. 

[0083] Fig. 8(b) shows a data format that may be used 
when a plurality of contents are stored on a medium, 
and all contents use the same encrypted data Enc(EKB, 
KEK) 805. In this case, data pointing to Enc(EKB, KEK) 
is added to the respective content data, instead of add- 
ing the same Enc(EKB, KEK) to the respective content 
data. 

[0084] Fig. 9 shows an example in which the content 
key encryption key KEK is employed as a renewed node 
key K(t)00 to be used instead of the node key K00 shown 
in Fig. 3. In the case where the device 3 in the group 
enclosed by the dotted line in Fig. 3 has been revoked 
because of exposure of secrecy of a key, if the enabling 
key block (EKB) shown in Fig. 9(a), data produced by 
encrypting the content key (Kcon) using the content key 
encryption key (KEK = K(t)00) shown in Fig. 9(b), and 
data produced by encrypting the content using the con- 
tent key (Kcon) are supplied to the other members in the 
group, that is, to the devices 0, 1 , and 2, the devices 0, 
1 , and 2 can acquire the content. 
[0085] A decryption procedure performed by the de- 
vice 0 is shown on the right-hand side of Fig. 9. First, 
the device 0 acquires the content key decryption key 
(KEK = K(t)00) from the received enabling key block by 
performing a decryption process usingthe leaf key K000 
held by the device 0. The device 0 then acquires the 
content key Kcon by means of decryption using K(t)00 
and finally acquires the content by means of decryption 
using the content key Kcon. Thus, the device 0 can ob- 



tain the content. Similarly, the devices 1 and 2 can ac- 
quire the content key encryption key (KEK = K(t)00) by 
processing the EKB according to their own procedures 
and can further acquire the content. 

5 [0086] Even if the devices 4, 5, 6, and so on of the 
other groups shown in Fig. 3 received similar data 
(EKB), they cannot acquire the content key encryption 
key (KEK= K(t)00) usingthe leaf keys or node keys held 
by them. The revoked device 3 can also not acquire the 

10 content key encryption key (KEK = K(t)00) using the leaf 
key or node keys held by the device 3. Thus, only the 
authorized devices can decrypt the content and can use 
the decrypted content. 

[0087] Thus, the above-described method of trans- 
15 mitting a content key using an EKB makes it possible to 
securely distribute an encrypted content using a small 
amount of data such that only authorized users can de- 
crypt the encrypted content. 

[0088] In the example described above, the enabling 

20 key block (EKB), the content key, and the encrypted 
content, are securely distributed via the network. Alter- 
natively, the enabling key block (EKB), the content key, 
and the encrypted content, may be stored on a storage 
medium such as a DVD or a CD and the storage medium 

25 may be supplied to a user thereby providing the enabling 
key block (EKB), the content key, and the encrypted 
content to the user. In this case, if the encrypted content 
and the enabling key block (EKB) are stored on the 
same storage medium so that the encrypted content can 

30 be decrypted using the content key that can be obtained 
by decrypting the enabling key block (EKB), it is possible 
to realize a simple content distribution system that al- 
lows only limited authorized user devices can use a dis- 
tributed encrypted content by decrypting it using a leaf 

35 key or node keys held by the user devices. 

[0089] Fig. 10 shows an example in which encrypted 
contents and enabling key blocks (EKB) are stored to- 
gether on a storage medium. In this specific example 
shown in Fig. 1 0, contents C1 to C4 are stored on a stor- 

40 age medium, and data indicating the correspondence 
between the respective contents and enabling key 
blocks (EKB) is stored on the same storage medium, 
and furthermore an enabling key block of version M 
(EKB_M) is also stored. For example, EKB_1 is used to 

45 produce a content key Kconl used to encrypt the con- 
tent Ct, and EKB_^2 is used to produce a content key 
Kcon2 used to encrypt the content C2. In this example, 
because the enabling key block (EKB Jvl) of version M 
is stored on the storage medium, and because the con- 

50 tents C3 and C4 are related to the enabling key block 
(EKB_M), it is possible to acq uire the content key for the 
contents C3 and C4 by decrypting the enabling key 
block (EKB_M). On the other hand, because EKB_1 and 
EKB_2 are not stored on the disk, it is needed to acquire 

55 them via another means such as a network communi- 
cation or another storage medium to decrypt the content 
keys C1 and C2. 

[0090] Fig. 1 1 shows a comparison between a proc- 
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ess of distributing a content key using an EKB and a 
process of distribution a content key according to the 
conventional technique, for case where the content key 
are distributed among a plurality of devices. The con- 
ventional technique is shown in the upper half area (a) 
of Fig. 11, and the technique using the enabling key 
block (EKB) according to the present invention is shown 
in the lower half area (b) of Fig. 11. In Fig. 11 . Ka(Kb) 
denotes data produced by encrypting Kb using Ka. 
[0091] In the conventional technique, as shown in (a), 
authentication and key exchange (AKE) are performed 
between devices to verify that transmitting and receiving 
devices are authorized devices and to produce a ses- 
sion key Kses to be used in common by both devices. 
If and only if the authentication is successfully passed, 
a content key Kcon is encrypted using the session key 
Kses and the resultant encrypted data is transmitted. 
[0092] For example, a PC shown in Fig. 1 1 (a) can ac- 
quire Kcon by decrypting encrypted content key Kses 
(Kcon) using a received session key. Furthermore, the 
PC can encrypt the acquired content key Kcon using a 
storage key Kstr held by the PC and store resultant en- 
crypted data into a memory of the PC. 
[0093] In Fig. 11(a), even in a case where a content 
provider wants to transmit data such that only a storage 
device 11 01 shown in Fig. 11 (a) can use the data, if there 
are a PC and a playback apparatus between the content 
provider and the storage device 1101 , it is needed to 
perform authentication as shown in Fig. 11 (a) and then 
transmit a content key encrypted using a session key. 
in this case, the PC and the playback apparatus existing 
between them can acquire the content key by decrypting 
the encrypted content key using the session key pro- 
duced via the authentication process and acquired by 
the PC and the playback apparatus. 
[0094] On the other hand, in the example shown in 
the lower half area (b) of Fig. 11 in which a content pro- 
vider transmits an enabling key block (EKB) and data 
(Kroot(Kcon) in the specific example shown in Fig. 11 
(b)) produced by encrypting a content koy Kcon using a 
node key or a root key that is obtained by processing 
the enabling key block (EKB), only a device, which can 
process the received EKB, can perform decryption to 
acquire the content key Kcon. 

[0095] Therefore, if an enabling key block (EKB) is 
produced such that it can be used only by a device lo- 
cated on the right end in Fig. 11(b), and if the enabling 
key block (EKB) is transmitted together with data pro- 
duced by encrypting a content key Kcon using a node 
key or a root key that can be obtained by processing the 
EKB, a device such as a PC or a playback apparatus 
existing between the content provider and the device on 
the right end cannot process the EKB using the leaf key 
or node key held in the PC or the playback apparatus. 
Therefore, it is possible to securely transmit a content 
key that can be used only an authorized device without 
necessitating a process between transmitting and re- 
ceiving devices, such as authentication, production of a 



session key, and encryption of the content key Kcon us- 
ing the session key. 

[0096] When it is desired to transmit a content key 
such that it can also be used by the PC and the playback 
apparatus, if an enabling key block (EKB) is produced 
such that it can be processed by any of these devices 
which should be allowed to use the content key, and if 
the resultant EKB is transmitted, then these device can 
acquire the content key. 

[Distribution of an authentication key using an enabling 
key block (EKB) (by means of common key 
cryptography)] 

[0097] In the distribution of data or a key using an en- 
abling key block (EKB) according to the above-de- 
scribed technique, the enabling key block (EKB) and the 
content or the content key that are transmitted between 
devices are encrypted into the same form. Therefore, 
there is a possibility that an. unauthorized copy is made 
by a so-called replay attack technique in which data is 
stolen and recorded by tapping a data transmission line 
and the recorded data is transferred later. To prevent 
data from being copied in an unauthorized manner, it is 
effective to perform authentication and key exchange as 
in the conventional technique. Thus, herein, a technique 
is disclosed in which an authentication key Kake used 
in authentication and key exchange is transmitted to a 
device,, using an enabling key block (EKB) according to 
the above-described technique thereby allowing the 
common authentication key to be used as a secure se- 
cret key and thus allowing authentication to be per- 
formed according to the common key cryptography 
technique. That is, in this technique, the authentication 
key is transmitted as message data encrypted by an 
EKB. 

[0098] Fig. 1 2 shows a mutual authentication method 
using common key cryptography (according to ISO/ 
IEC9798-2). In the example shown in Fig. 12, a common 
key cryptography technique based on the DES is em- 
ployed, another similar common key cryptography tech- 
nique may also be employed. In Fig. 12, a device B first 
generates a 64-bit random number Rb and transmits 
Rb, together with an identifier ID(b) of the device B, to 
a device A. In response to receiving Rb and ID(b), the 
device A generates a 64-bit random number Ra and en- 
crypts Ra, Rb, and ID(b) using a key Kab in the CBC 
mode of the DES, in the order of Ra, Rb, and ID(b). The 
resultant encrypted data is returned to the device B. 
Herein, the key Kab is a key that is used as a secret key 
in common by the devices A and B and that is stored in 
a storage device of each of the devices A and B. The 
encryption using the key Kab in the CBC mode of the 
DES may be performed as follows. In the process using 
the DES, the exclusive OR between the initial value and 
Ra is calculated and the result is encrypted by the DES 
encryption unit using a key Kab thereby obtaining en- 
crypted data E1 . The exclusive OR between E1 and Rb 
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is calculated and the result is encrypted by the DES en- 
cryption unit using the key Kab thereby obtaining en- 
crypted data E2. Furthermore, the exclusive OR be- 
tween trie encrypted data E3 and ID(b) is calculated, 
and the result is encrypted by the DES encryption unit 
using the key Kab thereby obtaining encrypted data E3. 
The obtained encrypted data E1 to E3 (Token-AB) are 
transmitted. 

[0099] If the device B receives the encrypted data, the 
device B decrypts the received data using the key Kab 
(authentication key) as the secret key used in common. 
More specifically, the decryption of the received data is 
performed as follows. First, the encrypted data E1 is de- 
crypted using the authentication key Kab to obtain the 
random vatue Ra. Thereafter, the encrypted data E2 is 
decrypted using the authentication key Kab. Rb is ob- 
tained by calculating exclusive OR between the result- 
ant decrypted data and E1. Finally, the encrypted data 
E3 is decrypted using the authentication key Kab, and 
exclusive OR between the resultant decrypted data and 
E2 is calculated to obtain ID(b). Of Ra, Rb, and ID(b) 
obtained via the above process, Rb and ID(b) are com- 
pared with those transmitted from the device B to verify 
whether they are identical. If the verification is success- 
fully passed, the device B determines that the device A 
is an authorized device. 

[0100] Thereafter, the device B generates a session 
key (Kses) which will be used after the authentication 
(the session key Kses is generated using a random 
number). Rb, Ra, and Kses are encrypted, in this order, 
using the authentication key Kab in the CBC mode of 
the DES and transmitted to the device A. 
[01 01 ] Upon receiving the data, the device A decrypts 
the received data using the authentication key Kab. The 
received data can be decrypted in a similar manner to 
decryption performed by the device B, and thus it is not 
described in further detail herein. Thus, Rb, Ra and 
Kses are obtained, and Rb and Ra are compared with 
the original data transmitted from the device A. Ifthe ver- 
ification is successfully passed, the device A determines 
that the device B is an authorized device. In communi- 
cation performed after the mutual authentication has 
been successfully passed, the session key Kses is used 
to secure the secrecy. 

[0102] In the case where the received data is deter- 
mined as being invalid in the above-described verifica- 
tion, the mutual authentication fails and the process is 
terminated. 

[01 03] I n the authentication process described above, 
the authentication key Kab is used in common by both 
devices A and B. This common key Kab is transmitted 
to the devices by means of the above-described tech- 
nique using an enabling key block (EKB). 
[01 04] More specifically, in the example shown in Fig. 
12, one of devices A and B produces an enabling key 
block (EKB) such that it can be decrypted by the other 
device, and said one of devices further encrypts the au- 
thentication key Kab using, the produced enabling key 



block (EKB) and transmits the resultant encrypted data 
to the other device. Alternatively, a third party may pro- 
duce an enabling key block (EKB) that can be used by 
both devices A and B, and may transmit an authentica- 

s tion key Kab encrypted using the produced enabling key 
block (EKB) to the devices A and B. 
[0105] Figs. 13 and 14 show examples of processes 
of transmitting a common authentication key Kake to a 
plurality of devices by means of the technique using an 

10 enabling key block (EKB). In the example shown in Fig. 
13, an authentication key Kake that can be decrypted 
by devices 0, 1 , 2, and 3 is transmitted to these devices. 
In the example shown in Fig. 14, of devices 0, 1,2, 3, 
the device 3 is revoked, and an authentication key that 

15 can be decrypted only by devices 0, 1 , 2 is transmitted. 
[0106] In the example shown in Fig. 13, data (b) pro- 
duced by encrypting an authentication key Kake using 
a renewed node key K(t)00 is transmitted together with 
an enabling key block (EKB) produced such that the re- 

20 newed node key K(t)00 can be obtained by decrypting 
the EKB using node keys and leaf keys held by the re- 
spective devices 0, 1,2, and 3. As shown on the right- 
hand side of Fig. 13, each device first acquires the re- 
newed node key K(t)00 by processing (decrypting) the 

25 EKB and then acquires the authentication key Kake by 
decrypting the encrypted authentication key Enc(K(t)00, 
Kake) using the acquired node key K(t)00. 
[0107] Even if one of the other devices 4, 5, 6, 7, and 
so on receives the same enabling key block (EKB), the 

30 device cannot process the EKB using a node key or a 
leaf key held by the device to acquire the renewed node 
key K(t)00. Thus, it is possible to securely transmit the 
authentication key only to authorized devices. 
[0108] On the other hand, in the example shown in 

35 Fig. 14, in a situation in which the device 3 in the group 
enclosed by the dotted line in Fig. 3 has been revoked 
because of exposure of secrecy of a key, an enabling 
key block (EKB) is produced such that it can be decrypt- 
ed only by the other members of the group, that is, the 

40 devices 0, 1 , and 2. andthe produced enabling key block 
(EKB) is transmitted. More specifically, the enabling key 
block (EKB) shown in Fig. 14(a) and the data, shown in 
Fig. 14(b), produced by encrypting the authentication 
key (Kake) using the node key (K(t)00) are transmitted 

45 together. 

[0109] The decryption procedure is shown on the 
right-hand side of Fig. 14. Each device 0, 1 , and 2 first 
acquires the renewed node key (K(t)00) from the re- 
ceived enabling key block by performing decryption us- 

50 ing a leaf key or a node key held by the device. There- 
after, each device acquires the authentication key Kake 
by performing decryption using K(t)00. 
[0110] Even if one of the devices 4, 5, 6, and so on of 
the other groups shown in Fig. 3 received similar data 

55 (EKB), it cannot acquire the renewed node key (K(t)00) 
using a leaf key or a node key held by it. The revoked 
device 3 can also not acquire the renewed node key (K 
(t)00) using a leaf key or a node key held by it. Thus, 
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only the authorized devices can decrypt the authentica- 
tion key and. can use it. 

[0111] Thus, the above-described method of trans- 
mitting an authentication key using an EKB makes it 
possible to securely transmit an encrypted authentica- 
tion key using a small amount of data such that only au- 
thorized users can decrypt the encrypted authentication 
key. 

[Distribution of a content key using a public key 
certificate and an enabling key block (EKB)] 

[01 1 2] Now, a method of distributing a content key us- 
ing a public key certificate and an enabling key block 
(EKB) is described below. First, a method of mutual au- 
thentication using 160-bit elliptic-curve cryptography 
which is one of public key cryptography schemes is de- 
scribed below with reference to Fig. 15l Although ECC 
is employed as the public key cryptography scheme in 
the process shown in Fig. 15, another similar symmetric 
key cryptography scheme may also be employed. Fur- 
thermore, the key size is not limited to 1 60 bits. In Fig. 
15, first, a device B generates a 64-bit random number 
Rb and transmits it to a device A. Upon receiving Rb, 
the device A generates a 64-bit random number Ra and 
a ransom number Ak smaller than a prime number p. 
Point Av = Ak {x} G is calculated by multiplying a base 
point G by Ak. A digital signature A.Sig for Ra, Rb, and 
Av (X and Y coordinates) is then generated and trans- 
mitted together with a public key certificate of the device 
A to the device B. Herein, Ra and Rb have a length of 
64 bits and the X and Y coordinates of Av have a length 
of 160 bits, and thus the digital signature is generated 
for a total length of 448 bits. 

[0113] Upon receiving the public key certificate of the 
device A, Ra, Rb, Av, and the digital signature A.Sig, the 
digital device B verifies whether Rb received from the 
device A is equal to the original value generated by the 
device B. If the verification indicates that Rb is equal to 
the original value, the digital signature written in the pub- 
lic key certificate of the device A is then verified using 
the public key of the certificate authority, and the public 
key of the device A is extracted. Thereafter, the digital 
signature A.Sig is verified using the extracted public key 
of the device A. 

[0114] Thereafter, the device B generates a random 
number Bk smallerthan the prime number p. Thereafter, 
point Bv = Bk {x} G is calculated by multiplying the base 
point G by Bk. A digital signature B.Sig for Rb, Ra, Bv 
(X and Y coordinates) is then generated and transmitted 
together with a public key certificate of the device B to 
the device A. 

[01 1 5] Upon receiving the public key certificate of the 
device B, Rb, Ra, Av, and the digital signature B.Sig, the 
digital device A verifies whether Ra received from the 
device B is equal to the original value generated by the 
device A. If the verification indicates that Ra is equal to 
the original value, the digital signature written in the pub- 



lic key certificate of the device B is then verified using 
the public key of the certificate authority, and the public 
key of the device B is extracted. Thereafter, the digital 
signature B.Sig is verified using the extracted public key 
of the device B. If the verification of the digital signature 
is successfully passed, the device A regards the device 
B as being an authorized device. 

[0116] If the mutual authentication is successfully 
passed, the device B calculates Bk{x} Av (by multiplying 
the point Av on the elliptic curve by Bk which is a random 
number), and the device A calculates Ak {x} Bv. Lower 
order 64 bits of the X coordinates of the resultant points 
are used as a session key during communication per- 
formed thereafter (in the case where 64-bit keys are 
used as symmetric keys according to the symmetric key 
cryptography). The session key may be generated from 
Y coordinates. Instead of employing lower-order 64 bits, 
another set of bits may also be employed. In secret com- 
munication performed after the mutual authentication, a 
digital signature may be added to data encrypted using 
a session key. 

[0117] In the case where the digital signature or the 
received data is determined as being invalid in the 
above-described verification, the mutual authentication 
fails and the process is terminated. 
[0118] Fig. 1 6 shows an example of a process of dis- 
tributing a content key using a public key certificate and 
an enabling key block (EKB). First, authentication is per- 
formed between a content provider and a PC by means 
of the public key cryptography technique described 
above with reference to Fig. 15. The content provider 
produces an EKB that can be decrypted using a node 
key or a leaf key held by a playback apparatus or a stor- 
age medium to which a content key is to be transmitted. 
Thereafter, the encrypted content key E(Kcon) pro- 
duced by encrypting the content key using a renewed 
node key and the enabling key block (EKB) are encrypt- 
ed using a session key Kses produced via the authen- 
tication between the content provider and the PC, and 
the resultant data is transmitted to the PC. The PC de- 
crypts, using the session key, the content key E(Kcon) 
encrypted using the renewed node key and the enabling 
key block (EKB), which were both encrypted using the 
session key, and transmits the resultant decrypted data 
to the playback apparatus and the storage medium. 
[0119] The playback apparatus and the storage me- 
dium acquire the content key Kcon by decrypting, using 
a node key or a leaf key held by them, the content key 
E(Kcon) encrypted using the renewed node key and the 
enabling key block (EKB). 

[0120] In this method, if and only if authentication be- 
tween the content provider and the PC is successfully 
passed, the content key E(Kcon) encrypted using the 
renewed node key and the enabling key block (EKB) are 
55 transmitted , thereby ensuring that data can be securely 
transmitted only to an authorized device even in a situ- 
ation in which secrecy of a node key has been exposed. 
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[Distribution of a program code using an enabling key 
block (EKB)] 

[0121] In the examples described above, data such 
as a content key, an authentication key, or the like is 
encrypted using an enabling key block (EKB) and result- 
ant encrypted data is transmitted. Various kinds of pro- 
gram codes may also be transmitted in a similar manner 
using an enabling key block (EKB). In this case, a pro- 
gram code is transmitted as message data encrypted 
using an EKB. The process is described in further detail 
beiow. 

[0122] Fig. 17 shows an example of a process of 
transmitting a program code between devices after en- 
crypting it using, for example, a renewed node key in- 
cluded in an enabling key block (EKB). A device 1701 
produces an enabling key block (EKB) that can be de- 
crypted using a node key or a leaf key held by a device 
1702 and also produces data by encrypting a program 
code using a renewed node key included in the enabling 
key block (EKB). The resultant enabling key block (EKB) 
and the encrypted data are transmitted to the device 
1702. The device 1702 acquires the renewed node key 
by processing the received EKB, and then acquires the 
program code by decrypting the encrypted program 
code using the acquired renewed node key. . 
[0123] In the example shown in Fig. 17, the device 
1702 further executes the acquired program code and 
returns the result to the device 1 701 . Depending on the 
result, the device 1701 performs a further process. 
[0124] As described above, by transmitting an ena- 
bling key block (EKB) and a program code encrypted 
using a renewed node key included in the enabling key 
block (EKB), it becomes possible to transmit the pro- 
gram code, which can be decrypted only by a specific 
device, to that specific device or a specific group shown 
in Fig. 3, 

[Addition of an integrity check value (ICV) to a content 
to be transmitted] 

[0125] A method is now described for preventing a 
content from being tampered with, by determining 
whether the content has been tampered with on the ba- 
sis of an integrity check value (ICV) calculated for the 
content. 

[0126] The integrity check value (ICV) of a content is 
calculated, for example, by applying a hash function to 
thecontentsuchthatlCV = hash(Kicv,C1,C2,...) where- 
in Kiev is an ICV generation key, and C1 and C2 are 
information associated with the content represented in 
message authentication codes (MAC). 
[0127] Fig. 18 illustrates an example of a process of 
producing an MAC value by means of DES encryption. 
As shown in Fig. 18, a message to be transmitted is di- 
vided into parts each consisting of 8 bytes (hereinafter; 
divided parts of the message are denoted by M1 } M2,..., 
MN). First, the exclusive OR between*an initial value (IV) 



and M1 is calculated (wherein the result is represented 
by 11 ). Thereafter, 11 is applied to a DES encryption unit 
to encrypt II using a key (K1) (wherein the encrypted 
output is denoted by E1 ) The exclusive OR between E1 

5 and M2 is then calculated, and the result 12 is applied to 
the DES encryption unit to encrypt it using a key K1 
(wherein the resultant output is denoted by E2). There- 
after, the above process is repeated until the all parts of 
the message are encrypted. The final output EN is em- 

10 ployed as a message authentication code (MAC). 

[0128] An integrity check value (ICV) of the content is 
produced by applying a hash function to the MAC value 
of the content and the ICV generation key. The ICV gen- 
erated on the basis of the content is compared with an 

15 ICV that has been produced, for example, when the con- 
tent is generated and that is guaranteed as valid. If both 
values are identical, the content is determined to be val- 
id without being tampered with. If they are different, the 
content is determined to have been tampered with. 

20 

[Distribution of a generation key Kiev of an integrity 
check value (ICV) using an EKB] 

[0129] A process of transmitting a generation key Kiev 

25 of an integrity check value (ICV) using an enabling key 
block (EKB) is described below. That is, in this case, the 
generation key Kiev of the integrity check value (ICV) 
authentication key is transmitted as message data en- 
crypted using the EKB. 

30 [0130] Figs. 19 and 20 show specific examples of 
manners of transmitting, using an enabling key block 
(EKB), an integrity check value generation key Kiev 
used to verify that the content has not been tampered 
with, in a situation in which the same content is trans; 

35 mitted to a plurality of device. 

[0131] In the example shown in Fig. 19, an ICV gen- 
eration key Kiev that can be decrypted by devices 0 : 1 , 
2, and 3 is transmitted to these devices. In the example 
shown in Fig. 20, of devices 0, 1, 2, 3, the. device 3 is 

40 revoked, and an ICV generation key Kiev that can be 
decrypted only by devices 0, 1 , 2 is transmitted. 
[0132] In the example shown in Fig. 19, data (b) pro- 
duced by encrypting an ICV generation key Kiev using 
a renewed node key K(t)00 is transmitted together with 

45 an enabling key block (EKB) produced such that the re- 
newed node key K(t)00 can be obtained by decrypting 
the EKB using node keys and leaf keys held by the re- 
spective devices 0, 1 , 2, and 3. As shown on the right- 
hand side of Fig. 19, each device first acquires the re- 

50 newed node key K(t)00 by processing (decrypting) the 
EKB and then acquires the ICV generation key Kiev by 
decrypting the encrypted ICV generation key Enc(X(t) 
00, Kiev) using the acquired node key K(t)00. 
[0133] Even if one of the other devices 4, 5, 6, 7, and 

55 so on receives the same enabling key block (EKB), the 
device cannot process the EKB using a node key or a 
leaf key held by the device to acquire the renewed node 
key K(t)00. Thus, it is possible to securely transmit the 
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ICV generation key only to authorized devices. 
[0134] On the other hand, in the example shown in 
Fig. 20, in a situation in which the device 3 in the group 
enclosed by the dotted line in Fig. 3 has been revoked 
because of exposure of secrecy of a key, an enabling s 
key block (EKB) is produced such that it can be decrypt- 
ed only by the other members of the group, that is, the 
devices 0,1, and 2, and the produced enabling key block 
(EKB) is transmitted. More specifically, the enabling key 
block (EKB) shown in Fig. 20(a) and the data, shown in 10 
Fig. 20(b), produced by encrypting the ICV generation 
key (Kiev) using the node key (K(t):00) are transmitted 
together. 

[0135] The decryption procedure is shown on the 
right-hand side of Fig. 20. Each device 0, 1, and 2 first 15 
acquires the renewed node key (K(t)00) from the re- 
ceived enabling key block by performing decryption us- 
ing a leaf key or a node key held by the device. There- 
after, each device acquires the ICV generation key Kiev 
by performing decryption using K(t)00. 20 
[0136] Even if one of the devices 4, 5, 6, and so on of 
the other groups shown in Fig. 3 received similar data 
(EKB), it cannot acquire the renewed node key (K(t)00) 
using a leaf key or a node key held by it. The revoked 
device 3 can also not acquire the renewed node key (K 25 
(t)00) using a leaf key or a node key held by it. Thus, 
only the authorized devices can decrypt the ICV gener- 
ation key and can use it. 

[0137] Thus, the above-described method of trans- 
mitting an ICV generation key using an EKB makes it 30 
possible to securely transmit the ICV generation key us- 
ing a small amount of data such that only authorized us- 
ers can decrypt the encrypted ICV generation key. 
[0138] As described above, by using the integrity 
check value (ICV) of the content, it is possible to prevent 35 
the EKB ad the encrypted content from being copied in 
an unauthorized manner. For example, as shown in Fig. 
21 , in a case where a content C1 and a content C2 are 
stored on a medium 1 together with an enabling key 
block (EKB) from which content keys associated with 40 
the contents C1 and C2 can be acquired, if the data is 
directly copied onto a medium 2, the copied EKB and 
contents can be used by any device that can decrypt the 
EKB. 

[0139] In contrast, in the example shown in Fig. 21(b), 
each authorized medium includes, stored thereon, an 
integrity check value (ICV(C1 , C2)) associated with con- 
tents in addition to the contents. Herein, ICV(C1, C2) 
denotes an integrity check value obtained by applying 
a hash function to the content C1 and the content C2 
such that ICV - hash(Kicv, C1 , C2). In the example 
shown in Fig. 21 (b), the content 1 and the content 2 are 
stored on a medium 1 in an authorized manner, and the 
integrity check value (ICV(C1 , C2)) produced on the ba- 
sis of the content C1 and the content C2 is also stored 
thereon. On the other hand, the content 1 is stored on 
a medium 2 in an authorized manner and the integrity 
check value (ICV(C1 )) produced on the basis of the con- 



tent C1 is also stored thereon. In this situation, if data 
{EKB. content 2} is copied from the medium 1 to the me- 
dium 2, a new integrity check value ICV(C1 , C2) is pro- 
duced by the medium 2, and it turns out that the new 
integrity check value is different from the integrity check 
value Kicv(C1) stored on the medium 2. Thus, it turns 
out that the content has been tampered with or a new 
content has been copied in an unauthorized manner. 
When a device plays back a medium, if, before starting 
playback, the device checks the ICV to determine 
whether the generated ICV and the original ICV stored 
on the medium are identical to each other, and if play- 
back is not performed when two values are not identical 
to each other, it is possible to an unauthorized copy of 
a content from being played back. 
[0140] To further enhance the security, the integrity 
check value (ICV) of a content may be rewritten into a 
value produced on the basis of data including a counter 
value such that ICV = hash(Kicv, counter + 1 , Ci C2,...), 
where the counter value (counter + 1 ) is incremented by 
1 each time the ICV is rewritten. It is required that the 
counter value be stored in a secure memory. 
[0141] In a case where an integrity check value (ICV) 
of a content cannot be stored on the same medium as 
that on which the content is stored, the integrity check 
value (ICV) of the content may be stored on a medium 
differently from the content. 

[0142] For example, when a content is stored on a 
read-only medium or a usual MO that does not have a 
copy protection capability, if an integrity check value 
(ICV) is stored on the same medium, the ICV can be 
rewritten by an unauthorized user, the security of the 
ICV cannot be achieved. In such a case, the ICV is 
stored on a secure medium on a host machine, and con- 
tent copy control (such as check-in/check-out, move) is 
performed using the ICV, thereby ensuring that the ICV 
is securely managed and making it possible to check 
whether the content has been tampered with. 
[0143] Fig. 22 shows a specific example of the proc- 
ess for the above purpose. In this example shown in Fig. 
22, contents are stored on a medium 2201 , such as a 
read-only medium or a usual MO, which does not have 
a copy protection capability, and an integrity check value 
(ICV) associated with these contents is stored on a se- 
cure medium 2202 on a host machine which is not al- 
lowed to be accessed by a user, thereby preventing the 
integrity check value (ICV) from being rewritten in an un- 
authorized manner; If, before a device starts to playback 
of the medium 2201 mounted thereon, a PC or a server 
serving as the host machine checks the ICV to deter- 
mine whether playback should be allowed, it is possible 
to prevent an unauthorized copy of a content or a tam- 
pered content from be played back. 



[0144] In the above examples, encryption keys are 
produced into the form of a hierarchical tree structure, 
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such as that shown in Fig. 3, including a root key, node 
keys, and leaf keys, and data such as a content key, an 
authentication key, an I CV generation key, or a program 
code is encrypted and transmitted together with an en- 
abling key block (EKB). The hierarchical tree structure s 
that defines the node keys or the like may be catego- 
rized according to the types of devices, and renewal of 
keys, transmission of encryption keys, and transmission 
of data may be in a more efficient manner as described 
below. 10 
[0145] Fig. 23 shows an example of categorization of 
the hierarchical tree structure. In this example shown in 
Fig. 23, a root key Kroot 2301 is disposed at the top of 
the hierarchical tree structure, node keys 2302 are dis- 
posed in middle levels, and leaf keys 2303 are disposed 15 
at the bottom. Each device has a set of keys including 
a leaf key of the device itself, the root key, and node 
keys existing in the path from the leaf key to the root key. 
[0146] By way of example, it is assumed herein that 
nodes in an{M}th level as counted from the top are de- 
fined as category nodes 2304. That is, the nodes in the 
{M}th level are employed to define specific categories 
of devices. One node at the {M}th level is employed as 
a top node, and nodes and leaves that exist at the (M+1 ) 
th level and lower levels in paths originating from that 
top node are defined to be included in the category as- 
signed to the top node. 

[0147] For example, one node 2305 in the {M}th level 
in Fig. 23 is employed to define a category of "memory 
sticks (trade mark)", and nodes and leaves existing in 
paths originating from this node are defined to corre- 
spond to various devices using a memory stick belong- 
ing to the category of "memory sticks". That is, a set of 
nodes including the node 2305 and associated lower- 
level nodes and leaves is defined to belonging to the 
category of memory sticks. 

[0148] Furthermore, a level that is lower than the {M} 
th level by a proper number of levels may be employed 
as sub-category nodes 2306. For example, as shown in 
Fig. 23, a node that exists in a path originating from the 
category . node 2305 of "memory sticks" and that is lo- 
cated two levels lower than the category node 2305 is 
employed as a sub-category node of "playback devices" 
included in the category of devices using memory sticks. 
Similarly, a node 2307 below the sub-category node 
2306 of playback devices is employed as a sub-catego- 
ry node of "telephones having a music playback capa- 
bility" included in the category of playback devices. At a 
further lower level, a sub-category node 2308 of "PHS" 
and a sub-category node 2309 of "portable telephone" 
are defined such that both sub-categories belong to the 
category of telephone having music playback capability. 
[0149] The categories and subcategories can be de- 
fined according to not only the types of devices but also 
manufacturers, content providers, or clearance institu- 
tions, and those node may be respectively managed by 
them. That is, the categories and subcategories may be 
defined so as to have arbitrary scopes in accordance 



with, for example, processing, management organiza- 
tions, or services provided (hereinafter, units in the cat- 
egories or sub-categories are generically referred to as 
entities). For example, if one category node is set as a 
top node for dedicated use of a game machine XYZ pro- 
vided by a game machine manufacturers, it becomes 
possible to sell game machines XYZ in which node keys 
and leaf keys below the top node are stored. After selling 
the game machines XYZ, encrypted contents or keys 
may be supplied or keys may be renewed by supplying 
an enabling key block (EKB) including the top node key 
and node keys and leaf keys below the top node so that 
only devices below the top node can use the supplied 
data. 

[0150] As described above, when one node is given 
as a top node, lower-level nodes arising from the top 
node are defined as belonging to a category or a sub- 
category assigned to that top node, thereby making it 
possible for a manufacturers or a content provide that 
manages one top node of one category or sub-category 
to produce an enabling key block (EKB) including that 
top node without having to taking into account the other 
categories or sub-categories and distribute the resultant 
enabling key block (EKB) to devices corresponding to 
the top node or the lower-level nodes arising from the 
top nodes, and thus making it possible to renew a key 
without exerting any influence on devices belonging to 
the other categories that do not belong to that top node. 



[0151] In the tree structure described earlier with ref- 
erence to Fig. 3, when a key such as a content key is 
sent to a specific device (leaf), an enabling key block 
(EKB) is produced such that it can be decrypted by a 
leaf key or a node key held by the device to which the 
key is to be sent, and the resultant enabling key block 
(EKB) is provided to the device. For example, in the tree 
structure shown in Fig. 24(a), when a key such as a con- 
tent key is transmitted to devices a, g, and j at corre- 
sponding leaves, an enabling key block (EKB) that can 
be decrypted by those nodes a, g, and j are produced 
and transmitted thereto. 

[0152] More specifically, when a content key K(t)con 
is encrypted using a renewed root key K(t)root and 
transmitted together with an EKB, the devices a, g, and 
j can acquire K(t)root by processing the EKB using the 
leaf key and the node keys shown in Fig. 24(b), and fur- 
ther can acquire the content key K(t)con by performing 
decryption using the acquired renewed root key K(t)root. 
[0153] Fig. 25 shows the enabling key block (EKB) 
that is transmitted in this specific case. The enabling key 
block (EKB) shown in Fig. 25 is produced in accordance 
with the EKB format described earlier in accordance 
with Fig. 6, and thus the EKB includes data (encrypted 
keys) and tags corresponding to the data. As described 
earlier with reference to Fig. 7, left (L) and right (R) com- 
ponent of each tag has a value of 0 or 1 depending on 
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whether data exits in L or R directions. 
[0154] If a device receives the enabling key block 
(EKB), the device sequentially decrypts the encrypted 
keys included in the enabling key block (EKB) on the 
basis of the tags thereby sequentially acquiring renewed 
keys from a level to a higher level. As shown in Fig. 25, 
the data size of the enabling key block (EKB) increases 
with the number of levels between the root and the 
leaves (the number of levels is referred to as the depth). 
The depth (number of levels) increases with the number 
of devices (leaves), and thus the data size of the EKB 
becomes great when keys are transmitted to a great 
number of devices. 

[0155] A technique of reducing the data size of the 
enabling key block (EKB) is described below. Fig. 26 
shows an example of an enabling key block (EKB) sim- 
plified depending on the devices to which keys are trans- 
mitted. 

[0156] As in the example shown in Fig. 25, it is also 
assumed that a key such as a content key is transmitted 
to devices a, g, and j at corresponding leaves. As shown 
in Fig. 26(a), a tree structure is produced such that it 
includes only those devices to which the key is to be 
transmitted. Inthis case, the tree structure shown in Fig. 
26(b) is produced on the basis of the tree structure 
shown in Fig. 24(b). In a path from Kroot to Kj, there is 
no path branching from the path from Kroot to Kj, and 
thus this path can be represented by only one branch. 
On the other hand, to reach Ka or Kg from Kroot, it is 
needed to branch at K0 to Ka or Kg. Thus, the tree can 
be formed so as to have two branches as shown in Fig. 
26(a). 

[0157] As shown in Fig. 26(a), the resultant tree has 
a simplified form including only one node KO. An ena- 
bling key block (EKB) used to distribute renewed keys 
can be produced on the basis of this simplified tree. The 
tree shown in Fig. 26(a) can be produced by reconstruct- 
ing the original tree such that a binary tree is first pro- 
duced such that it includes only paths at the lower ends 
of which there are endpoint nodes or leaves that are al- 
lowed to decrypt the enabling key block (EKB), and then 
unnecessary nodes are removed from the tree. The en- 
abling key block (EKB) used to distribute renewed keys 
is produced on the basis of only keys corresponding to 
the nodes or leaves included in this reconstructed hier- 
archical tree. 

[0158] The enabling key block (EKB) described above 
with reference to Fig. 25 includes all encrypted keys ex- 
isting in paths from respective leaves a, g. and j to Kroot. 
In contrast, the simplified EKB includes only encrypted 
keys at nodes included in the simplified tree. As shown 
in Fig. 26(b), each tag is represented by 3 bits. The sec- 
ond and third bits are used in the same manner as in 
the example shown in Fig. 25. That is, the second bit 
has a value of 0 or 1 depending on whether there is data 
in the L (left) direction, and the third bit has a value of 0 
or 1 depending on whether there is data in the R (right) 
direction. The first bit is used to indicate whether the 



EKB includes an encrypted key at the node correspond- 
ing to the tag. When an encrypted key is included, the 
first bit is set to 1 , while it is set to 0 if no encrypted key 
is included. 

5 [01 59] The data size of the enabling key block (EKB) , 
which is provided to devices (leaves) via a data commu- 
nication network or provided by supplying a storage me- 
dium on which the EKB is stored, can be greatly reduced 
by employing the structure shown in Fig. 26(b) com- 
pared with the structure shown in Fig. 25. When each 
device receives the enabling key block (EKB) shown in 
Fig. 26, the device sequentially decrypts only the data 
at locations where the first bit of the corresponding tags 
is 1 , thereby obtaining all necessary decrypted keys. 
More specifically, the device a decrypts encrypted data 
Enc(Ka, K(t)0) using a leaf key Ka thereby acquiring a 
node key K(t)0, and decrypts encrypted data Enc(K(t)0, 
K(t)root) using the node key K(t)0 thereby acquiring K 
(t)root. On the other hand, the device j decrypts encrypt- 
ed data Enc(Kj, K(t)root) using a leaf key Kj thereby ac- 
quiring K(t)root. 

[0160] As descried above, if a new simplified tree 
structure including only devices to which data is to be 
transmitted is produced, and if an enabling key block 
(EKB) is produced using only leaf keys and node keys 
included in the simplified tree, the resultant enabling key 
block (EKB) becomes small in data size : and thus it be- 
comes possible to transmit the enabling key block (EKB) 
in an efficient manner. 

[Distribution of a key using a simplified EKB (2)] 

[0161] A technique of further simplifying the enabling 
key block (EKB) produced on the basis of the simplified 
tree shown in Fig. 26, thereby further reducing the data 
size and thus making it possible to perform processing 
in an efficient manner. 

[0162] In the example described above with reference 
to Fig. 26, the tree is produced by reconstructing the 
original tree such that a binary tree is first produced such 
that it includes only paths at the lower ends of which 
there are endpoint nodes or leaves that are allowed to 
decrypt the enabling key block (EKB), and then unnec- 
essary nodes are removed from the tree. The enabling 
key block (EKB) used to distribute renewed keys is pro- 
duced on the basis of only keys corresponding to the 
nodes or leaves included in this reconstructed hierarchi- 
cal tree. 

[0163] On the basis of the reconstructed hierarchical 
so tree shown in Fig. 26(a), an enabling key block (EKB) is 
produced as shown in Fig. 26(b) so that leaves a, g, and 
j can acquire renewed root key K(t)root, and the result- 
ant enabling key block (EKB) is transmitted. Via the 
processing of the enabling key block (EKB) shown in 
55 Fig. 26(b), the leaf j can acquire the root key K(t)root by 
performing only one decryption process in which Enc 
(Kj : K(t)root) is decrypted. However, the leaves a and g 
have to first decrypt Enc(Ka, K(t)0) or Enc(Kg, K(t)0) to 
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acquire K(t)0 and then decrypt Enc(K(t)0, K(t)root) to the 
root key K(t)root. That is, leaves a and g have to perform 
a two-step process for decryption. 
[0164] In a case where the node K0 functions as a sub 
root node that manages lower-level leaves a and g, the 5 
hierarchical tree reconstructed into the simplified form 
as shown in Fig. 26 may be useful to confirm that leaves 
a and b have acquired renewed keys. However, if the 
node K0 does not mange the lower-level leaves, or if, 
although the node K0 manages the lower-level leaves, 10 
providing of a renewed key from a higher-level node is 
allowed, then the reconstructed hierarchical tree shown 
in Fig. (2) may be further simplified by removing the 
node KO, and an enabling key block (EKB) may be pro- 
duced on the basis of this further simplified tree. 
[0165] An example of such an enabling key block 
(EKB) is shown in Fig. 27. As in the example shown in 
Fig. 26, it is also assumed herein that a key such as a 
content key is transmitted to devices a, g, and j at cor- 
responding leaves. As shown in Fig. 27(a), a tree is pro- 
duced such that the root Kroot is directly connected to 
the respective leaves a, g, and j. 
[0166] Thus, as shown in Fig. 27(a), the resultant tree 
has a structure that can be obtained by removing the 
node KO from the reconstructed hierarchical tree shown 
in Fig. 26(a). The enabling key block (EKB) used to dis- 
tribute renewed keys is produced on the basis of this 
simplified tree. The tree shown in Fig. 27(a) is a hierar- 
chical tree reconstructed so as to include only paths that 
directly connect the root and leaves that are allowed to 
decrypt the enabling key block (EKB). The enabling key 
block (EKB) used to distribute renewed keys is pro- 
duced on the basis of only keys corresponding to the 
leaves included in this reconstructed hierarchical tree. 
[0167] In the specific example shown in Fig. 27(a), the 
endpoint nodes are used as leaves. Also in a case 
where the highest-level node distribute keys to middle- 
level and lower-level nodes, the tree may be simplified 
by directly connecting the highest-node to a middle-level 
or lower-level node, an enabling key block (EKB) may 
be produced on the basis of the simplified tree, and keys 
may be transmitted using the resultant enabling key 
block (EKB). As described above, the reconstructed hi- 
erarchical tree has a tree structure in which the top node 
thereof is directly connected to endpoint nodes or 
leaves. In this simplified tree, the number of paths 
branching from the top node is not limited two, but the 
top node may have three or more branching paths de- 
pending on the number of the distribution nodes or 
leaves. 

[01 68] The enabling key block (EKB) described above 
with reference to Fig. 25 includes encrypted data corre- 
sponding to all keys in paths from the respective leaves 
a, g, and j to Kroot. In the example shown in Fig. 26, the 
enabling key block (EKB) includes the leaf keys as- 
signed to the leaves a, g, and j, the node K0 shared by 
a and g, and the root key. In contrast, in the enabling 
key block (EKB) on the basis of the simplified hierarchi- 



cal tree shown in Fig. 27(a), the key at the node K0 is 
removed, and thus, as shown in Fig. 27(b), it has a fur- 
ther reduced data size. 

[0169] The enabling key block (EKB) shown in Fig. 27 
(b) ; as in the enabling key block (EKB) shown in Fig. 26 
(b) : includes 3-bit tags. The second and third bits are 
used in the same manner as in the example shown in 
Fig. 26. That is, the second bit has a value of 0 or 1 ' 
depending on whether there is data in the L (left), direc- 
tion, and the third bit has a value of 0 or 1 depending on 
whether there is data in the R (right) direction. The first 
bit is used to indicate whether the EKB includes an en- 
crypted key at the node corresponding to the tag. When 
an encrypted key is included, the first bit is set to 1 . while 
it is set to 0 if no encrypted key is included. 
[0170] Using the enabling key block (EKB) shown in 
Fig. 27(b), the respective leaves a, g, and j can acquire 
the root key K(t)root by performing only one process of. 
decrypting Enc(Ka } K(t)root), Enc(Kg, K(t)root) or Enc 
(Kj, K(t)root). 

[0171 ] An enabling key block (EKB) on the basis of a 
tree reconstructed into a simplified form including a top 
node and endpoint nodes or leaves directly connected 
to the top node is produced on the basis of only those 
keys corresponding to the top node. and the endpoint 
nodes or leaves of the reconstructed tree, as shown in 
Fig. 27(b). 

[0172] By building a new simplified tree structure in- 
cluding only devices to which an enabling key block 
(EKB) is to be supplied and by producing the enabling 
key block (EKB) using only keys included in the resultant 
simplified tree or keys shared by leaves, as is the case 
with the enabling key blocks (EKB) described above 
with reference to Fig. 26 or 27, the resultant enabling 
key block (EKB) becomes small in data size, and thus 
it becomes possible to transmit the enabling key block 
(EKB) in an efficient manner. 

[0173] The simplified hierarchical tree structure is 
useful in particularwhen EKB's are managed on the ba- 
sis of category tress, wherein the category tree is one 
type of subtree as will be descried below. The category 
tree is a set of nodes or leaves selected from nodes or 
leaves of an original key distribution tree. A category 
tree may be formed in various aspects. For example, a 
category tree may be a set of nodes or leaves that are 
combmed together in accordance with the device type, 
the device supplier, the content provider, or the clear- 
ance institution, or in accordance with a common feature 
in terms of process, management, or services provided. 
Devices classified into one category are assigned to one 
category tree. For example, if constructing a simplified 
tree including top nodes (subroots) of a plurality of cat- 
egory trees in a similar manner as described above, and 
if an EKB is produced on the basis of the constructed 
tree, then the resultant simplified enabling key block 
(EKB) can be decrypted only by devices belonging to 
any one of the selected category trees. The manage- 
ment on the basis of the category trees will be described 
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in detail later. 

[0174] The enabling key block (EKB) may be stored 
on an information storage medium such as an optical 
disk or a DVD. For example, an enabling key block 
(EKB) including a data part including encrypted key data 
and a tag part including location identification data iden- 
tifying the locations of the encrypted key data in a hier- 
archical tree structure may be stored together with mes- 
sage data such as content data encrypted using a re- 
newed node key on an information storage medium, and 
the resultant information storage medium may be pro- 
vided to devices. Each device can sequentially extract 
encrypted key data included in the enabling key block 
(EKB) in accordance with the identification data in the 
tag field, and can decrypt the extracted encrypted key 
data thereby acquiring a key needed to decrypt a con- 
tent and thus using the content. Of course, the enabling 
key block (EKB) may be transmitted via a network such 
as the Internet. 

[Management of EKB on a category tree basis] 

[0175] A manner of managing nodes or leaves in a 
tree structure for use in key distribution in accordance* 
with a block or a set of nodes or leaves is described be- 
low. Herein, a block, which is a set of nodes or leaves, 
refers to as a category tree. A category tree may be 
formed in various aspects. For example, a category tree 
may be a set of nodes or leaves that are combined to- 
gether in accordance with the device type, the device 
supplier, the content provider, or the clearance institu- 
tion, or in accordance with a common feature in terms 
of process, management, or services provided. 
[0176] The category tree may be described in further 
detail with reference to Fig. 28. Fig. 28(a) shows a man- 
ner of managing a tree structure in units of category 
trees. In Fig. 28(a), each category tree is represented 
by one triangle. Each category tree, for example, that 
denoted by reference numeral 2701 , includes a plurality 
of nodes. Fig. 28(b) shows a node structure in one cat- 
egory tree. Each category tree is constructed in the form 
of a binary tree including one top node and a plurality of 
nodes at lower levels. Herein, a top node, such as that 
denoted by reference numeral 2702, of each category 
tree is referred to as a sub- root. 

[0177] As shown in Fig. 28(c), there are leaves, that 
is, devices, at lower ends of the tree. Any device belongs 
to one of category trees each including one top node 
2702 serving as a sub-root and a plurality of leaves cor- 
responding to devices. 

[0178] As can be seen from Fig. 28(a), category trees 
have a hierarchical structure, as described below with 
reference to Fig. 29. 

[0179] Fig. 29(a) illustrates an example of the hierar- 
chical structure in a simplified fashion. In this specific 
example, the hierarchical category tree structure in- 
cludes category trees A01 to Ann at a certain level below 
Kroot. At a level just below the category trees A1 to An, 



category trees B01 to Bnk are disposed. At a next lower 
level, category trees C1 to Cnq are disposed. As shown 
in Figs. 29(b) and (c), each category tree has a tree 
structure in which nodes and leaves are disposed at a 

5 plurality of levels. 

[0180] For example, the category tree Bnk has a tree 
structure including, as shown in Fig. 28(b), a top node 
2811 serving as a sub-root, endpoint nodes 2812, and 
other nodes located between the top node 281 1 and the 

10 endpoint nodes 281 2. The category tree is assigned an 
identifier Bnk. By managing the nodes within the cate- 
gory tree Bnk independently for the category tree Bnk 
thereby managing lower-level category trees each of 
which includes, as its top node, one of endpoint nodes 

15 281 2. On the other hand, the category tree Bnk is man- 
aged by a higher-level (parent) category tree Ann one 
of endpoint nodes 281 1 of which is included, as the sub- 
root 281 1 , in the category tree Bnk. 
[0181] As shown in Fig. 28(c), a category tree Cn3 has 

20 a tree structure including a top node 2851 serving as a 
sub-root, endpoint nodes 2852 corresponding to re- 
spective devices that are leaves in this case, and other 
nodes between the top node 2851 and the endpoint 
nodes 2852. This category tree is assigned an identifier 

25 cn3. By managing the nodes and leaves within the cat- 
egory tree Cn3 independently for the category tree Cn3 
thereby managing leaves (devices) at the endpoint 
nodes 2852. On the other hand, the category tree Cn3 
is managed by a higher-level (parent) category tree Bn2, 

30 one of endpoint nodes of which is included : as the sub- 
root 2851, in the category tree Cn3. Herein, the key 
management of each category tree refers to, for exam- 
ple, renewal of a key, revoking, or the like, as will be 
described in detail later. 

35 [0182] In each device corresponding to a leaf in a cat- 
egory tree at the bottom, a leaf key of the category tree, 
to which that device belongs, and node keys at respec- 
tive nodes existing in a path from the leaf to the top node 
serving as the sub-root node of that category tree are 

40 stored. For example, for a device at an endpoint node 
2852, keys corresponding to nodes in a path from the 
endpoint node (leaf) 2852 to the sub-root node 2851 are 
stored. 

[0183] The structure of the category tree is further de- 
45 scribed with reference to Fig. 30. Each category tree can 
has a tree structure including a various levels. The depth 
(number of levels) may be set depending on the number 
of lower-level (child) category trees each corresponding 
to endpoint nodes of that category tree or depending on 
so the number of devices to leaves. 

[0184] A category tree structure shown in Fig. 30(a) 
may be embodied as shown in Fig. 30(b). Herein, a root 
tree is a tree located at the top and the root tree has a 
root key. A plurality of lower-level category trees A, B, 
55 and Care disposed at respective endpoint nodes of the 
root tree; A further-lower level category tree D is dis- 
posed below the category tree C. In the category tree 
C2901 , one or more endpoint nodes are reserved as re- 
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served nodes 2950 so that another lower-level category 
tree can be added in the future by using the reserved 
node 2950. For example, a category tree C2902 having 
a multilevel tree structure may be added by assigning 
the reserved node 2950 as the top node of the new cat- 
egory tree. 

[0185] The reserved nodes are described in further 
detail below with reference to Fig. 31 . A category tree A 
(301 1 ) has lower-level category trees B, C, D, and so on 
managed by the category tree A (301 1) : and also has 
one reserved node 3021 . For example, the number of 
lower- level category trees may be increased in such a 
manner that the reserved node 3021 is assigned to a 
lower- level category A' (3012), and further lower-level 
category trees F and G may be connected to endpoint 
nodes of the lower-level category tree A' (3012). The 
lower- level category tree A* (301 2) may reserve at least 
one endpoint node 3022 so that another lower-level cat- 
egory tree A" (3013) maybe added.The lower-level cat- 
egory tree A" (301 3) may reserve one or more endpoint 
nodes. By reserving endpoint nodes in the above-de- 
scribed manner, it becomes possible to increase the 
number of lower- level category trees managed by a cer- 
tain category tree without limitation. The number of re- 
served category trees is not limited to one, butaplurality 
of endpoints may be reserved. 

[0186] Each category tree may produce an enabling 
key block (EKB) independently of the other category 
trees, and key renewal and revocation may be per- 
formed independently of the other category trees. As 
shown in Fig. 31, enabling key blocks (EKB's) are as- 
signed to respective category trees A, A', and A". These 
enabling key blocks (EKB's) may be managed by, for 
example, a device manufacturers that manages the cat- 
egory trees A, A', and A". 

[Registration of a new category tree] 

[0187] Registration of a new category tree is de- 
scribed below. Fig, 32 shows a registration processing 
sequence. In the sequence shown in Fig. 32, a new 
(child) category tree (N-En) to be added to a tree struc- 
ture issues a new registration request to an upper-level 
(parent) category tree (P-En). Each category tree has 
its own public key according to the public key cryptog- 
raphy scheme. When the new category tree issues the 
registration request, it transmits its public key to the up- 
per-level category tree (P-En). 

[0188] Upon receiving the registration request, the 
upper-level category tree (P-En) transfers the received 
public key of the new (child) category tree (N-En) to a 
certificate authority (CA) to receive a public key of the 
new (child) category tree having a signature of the CA. 
The above procedure is performed in mutual authenti- 
cation between the upper-level category tree (P-En) and 
the new (child) category tree (N-En). 
[0189] If the authentication of the category tree re- 
questing for new registration is completed via the above 



process, the upper-level category tree (P-En) gives per- 
mission of the registration of the new (child) category 
tree (N-En) and transmits a node key assigned to the 
new (child) category tree to the new (child) category tree 
5 (N-En). This node key corresponds to one of endpoint 
nodes of the upper-level category tree (P-En), and also 
corresponds to the top node or a sub-root key of the new 
(child) category tree (N-En). 

[0190] After the completion of the transmission of the 
10 node key, the new (child) category tree (N-En) builds a 
tree structure of the new (child) category tree (N-En) and 
sets the received sub-root key at the top node of the tree 
structure. Furthermore, keys are set at the respective 
nodes and leaves, and an enabling key block (EKB) as- 
15 sociated with the category tree is produced. An enabling 
key block (EKB) associated with a category tree is re- 
ferred to as a sub- EKB. 

[0191] On the other hand, the upper-level category 
tree (P-En) produces a sub-EKB associated with the up- 
20 per-level category tree (P-En) such that an endpoint 
node, which was made active when the new (child) cat- 
egory tree was connected thereto, is reflected in the 
sub-EKB. 

[0192] After the new (child) category tree (N-En) pro- 

25 duced the sub-EKB including the node keys and leaf 
keys within the new (child) category tree (N-En), the new 
(child) category tree (N-En) transmits the resultant 
sub-EKB to the upper-level category tree (P-En). 
[0193] Upon receiving the sub-EKB from the new 

30 (child) category tree (N-En), the upper-level category 
tree (P-En) transmits the received sub-EKB together 
with the renewed sub-EKB of the upper-level category . 
tree (P-En) to a key distribution center (KDC). 
[0194] On the basis of sub-EKB's of all category trees, 

35 the key distribution center (KDC) can produce an EKB 
in various manners. For example, the EKB can be pro- 
duced such that only a specified category tree or a spec- 
ified device can decrypt the EKB. If the EKB produced 
so as to be allowed to be decrypted by a specified cat- 

40 egory tree or device is provided to, for example, a con- 
tent provider, and if the content provider encrypts a con- 
tent key on the basis of the received EKB and supplies 
the encrypted content key via a network or supplies a 
storage medium on which the encrypted key is stored, 

45 it is becomes possible to provide a content such that the 
content can be used only by the specified device. 
[0195] The manner of registration of a sub-EKB of a 
new category tree at a key distribution center (KDC) is 
not limited to sequentially transferring the sub-EKB via 

50 an upper-level category tree, but registration may also 
be possible by directly transmitting the sub-EKB from 
the new category tree to the key distribution center 
(KDC) without passing it via the upper-level category 
tree. 

55 [0196] The correspondence between an upper-level 
category tree and a lower-level category tree that is 
newly added to the upper-level category tree is de- 
scribed below with reference to Fig. 33. By providing, as 
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a top node of the new category tree to be added, one 
endpoint node 3201 of the upper-level category tree to 
the lower-level category tree, the lower-level category 
tree can be added as one of category trees that are man- 
aged by the upper-level category tree. As will be de- 
scribed in detail later, category trees managed by the 
upper- level category tree refer to those category trees 
that can be revoked by the upper- level category tree. 
[0197] As shown in Fig. 33, if a new category tree is 
added to an upper-level category tree, the same one 
node acts as one endpoint node or leaf 3201 of the up- 
per-level category tree and also as the top node 3202 
of the newly added category tree. That is, one endpoint 
node serving as one leaf of the upper-level node is set 
to be the sub-root of the newly added category tree. By 
performing the setting in the above-described manner, 
the newly added category tree becomes one of active 
category trees constituting the total tree structure. 
[0198] Fig. 34 shows an example of a renewed EKB 
that is produced by an upper-level category tree when 
a new category tree is added. That is, Fig. 34 shows an 
example of a sub-EKB that is produced by the upper- 
level category tree when, in a situation in which the up- 
per-level category tree has a tree structure including, as 
shown in Fig. 34(a) ; an active endpoint node (node 000) 
3301 and an active endpoint node (node 001 ) 3302, an 
endpoint node (node 100) 3303 thereof is provided to 
the new category tree. 

[0199] Thesub-EKB has a format shown in Fig. 34(b). 
That is, the sub-EKB is a list of a high-level node key 
encrypted using an active endpoint node key, a higher- 
level node key encrypted using the upper-level node 
key,..., and finally a sub-root key. The sub-EKB is pro- 
duced according to this format. Each category tree has 
its own EKB in the form of encrypted data including, as 
with the sub-EKB shown in Fig. 34(b), a high-level node 
key encrypted using an active endpoint node key or leaf 
key, a higher-level node key encrypted using the high- 
level node key,..., and finally a sub-root. The EKB of 
each category tree is managed by that category tree it- 
self. 

[Revocation under the management of a category tree] 

[0200] Revocation of a device or a category tree per- 
formed in a situation in which the key distribution tree is 
managed on a category tree by category tree basis is 
described below. In the examples shown in Figs. 3 and 
4, an enabling key block (EKB) is produced such that 
the resultant enabling key block (EKB) can be decrypted 
only specified devices in the tree structure but a revoked 
device cannot decrypt the resultant enabling key block 
(EKB). In the examples shown in Figs. 3 and 4, revoca- 
tion is performed for a device assigned to a specific leaf 
in the tree structure. In a case where management is 
performed on a category tree basis, revocation can be 
performed on a specific category tree. 
[0201] Referring Fig. 35 and following figures, a rev- 



ocation process performed in a situation in which man- 
agement is performed on a category tree basis is de- 
scribed below. Fig. 53 shows a process of revoking a 
category tree at the lowest level in the tree structure in- 

5 eluding a plurality of category trees. In this case, devices 
belonging to the revoked category tree are ail revoked. 
[0202] Fig. 35(a) shows a key distribution tree struc- 
ture managed on the basis of category trees. A root 
node is disposed at the top of the tree, and category 

10 trees A01 to Ann are disposed at a certain level below 
the root node. Category trees B01 to Bnk are disposed 
at a lower level, and category trees C1 to Cn are dis- 
posed at a further lower level. Category trees at the low- 
est level have endpoint nodes (leaves) assigned to re- 

15 spective devices such as a recording/playing-back ap- 
paratus arid a playback apparatus. 
[0203] Revocation is performed individually by the re- 
spective category trees. For example, the category 
trees C1 to Cn at the lowest level can revoke a device 

20 at a leaf. Fig. 35(b) shows a tree structure of a category 
tree Cn (3430) that is one of category trees at the lowest 
level. The category tree Cn (3430) has atop node 3431 , 
and a plurality of devices are assigned to respective 
leaves at the endpoint nodes. 

25 [0204] When, for example, a device 3432 assigned to 
a leaf at a certain endpoint node should be revoked, the 
category tree Cn (3430) renews the category tree Cn 
itself and produces an enabling key block (sub-EKB) 
consisting of node keys and leaf keys included in the 

30 renewed category tree Cn. This enabling key block can- 
not be encrypted by the revoked device 3432 but can 
be encrypted only by devices assigned to the other 
leaves. An manager of the category tree Cn produces 
such an enabling key block as a renewed sub-EKB. 

35 More specifically, node keys at nodes 3431 , 3434, and 
3435 in a path from the sub-root to the device 3432 to 
be revoked are renewed, and a renewed sub-EKB is 
produced into the form of encrypted key data such that 
the renewed node keys are reflected in the renewed 

40 sub-EKB thereby ensuring that the renewed sub-EKB 
can be decrypted only by leaf devices other than the re- 
voked device 3432. This revocation process is equiva- 
lent to the revocation process described above with ref- 
erence to Figs. 3 and 4, if the root key is replaced with 

45 the sub-root key that is a top node key of the category 
tree. 

[0205] The enabling key block (sub-EKB) renewed via 
the revocation process performed by the category tree 
Cn (3430) is transmitted to a higher- level category tree. 
50 in this specific example, the high-level category tree is 
a category tree Bnk (3420), which includes, as one of 
endpoint nodes, the top node 3431 of the category tree 
Cn (3430). 

[0206] If the category tree Bnk (3420) receives the en- 
55 abling key block (sub-EKB) from the lower-level catego- 
ry tree Cn (3430), the category tree Bnk (3420) replaces 
the key assigned to the endpoint node 3431 of the cat- 
egory tree Bnk (3420)- corresponding to the top. node 
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3431 of the category tree Cnk (3430) with the renewed 
key included in the enabling key block received from the 
lower-level category tree Cn (3430), and the category 
tree Bnk (3420) renews its own sub-EKB. Fig. 35(c) 
shows the tree structu re of the category tree Bnk (3420) . 
In the category tree Bnk (3420) shown in Fig. 35(c), it is 
needed to renew node keys in a path from the sub-root 
3421 to the endpoint node 3431 connected to the cate- 
gory tree including the device to be revoked. More spe- 
cifically, it is needed to renew node keys assigned to 
nodes 3421 , 2424, and 3425 in the path connected to 
the node 3431 of the category tree that has transmitted 
the renewed sub-EKB. After renewing the node keys 
corresponding to these nodes, the category tree Bnk 
(3420) produces its renewed sub-EKB so as to reflect 
the renewed node keys. 

[0207] The renewed enabling key block (sub-EKB) 
produced by the category tree Bnk (3420) is transmitted 
to a further higher-level category tree. In this specific 
example, the further higher-level category tree is a cat- 
egory tree Ann (3410), which includes, as one of end- 
point nodes, the top node 3421 of the category tree Bnk 
(3420). 

[0208] If the category tree Ann (3410) receives the en- 
abling key block (sub-EKB) from the lower-level catego- 
ry tree Bnk (3420), the category tree Ann (341 0) replac- 
es the key assigned to the endpoint node 3421 of the 
category tree Ann (3410) corresponding to the top node 
3421 of the category tree Bnk (3420) with the renewed 
key included in the enabling key block received from the 
lower-level category tree Bnk (3420), and the category 
tree Ann (3410) renews its own sub-EKB. Fig. 35(d) 
shows the tree structu re of the category tree Ann (341 0) . 
In the category tree Ann (3410) shown in Fig. 35(d), it 
is needed to renew node keys assigned to nodes 3411 , 
341 4, and 341 5 in a path from the sub-root 341 1 to the 
endpoint node 3421 connected to the category tree that 
has transmitted the renewed sub-EKB. After renewing 
the node keys corresponding to these nodes, the cate- 
gory tree Ann (341 0) produces its renewed sub-EKB so 
as to reflect the renewed node keys. 
[0209] The above-described process is performed for 
further higher-level category trees until the root category 
tree shown in Fig. 30(b) has been renewed. Via the se- 
quence of processes described above, revocation of the 
device is completed. The renewed sub-EKB's produced 
by the respective category trees are finally transmitted 
to the key distribution center (KDC) and stored therein. 
The key distribution center (KDC) produces various 
EKB's on the basis of all renewed sub-EKB's. Each re- 
newed EKB has a form of an encrypted key block that 
cannot be decrypted by the revoked device. 
[0210] The sequence of device revocation processes 
is shown in Fig. 36. In the sequence shown in Fig. 36, 
a device management category tree (D-En) at the bot- 
tom of the tree structure performs key renewal needed 
to revoke a leaf from the device management category 
tree (D-En) and produces a renewed sub-EKB(D) of the 



device management category tree (D-En). The renewed 
sub-EKB(D) is transmitted to a higher-level category 
tree. Upon receiving the renewed sub-EKB(D), the high- 
er-level (parent) category tree (P1 -En) renews the node 

5 key assigned to the endpoint node corresponding to the 
top node of the renewed sub-EKB(D) and also node 
keys assigned to nodes in the path from that endpoint 
node to the sub-root, and then produces a renewed 
sub-EKB(PI) so as to reflect the renewed node keys. 

10 The above-described process is performed for further 
higher-level category trees, and all renewed sub-EKB's 
that are finally obtained are stored in the key distribution 
center (KDC) and managed thereby. 
[0211] Fig. 37 shows an example of a renewed ena- 

15 bling key block (EKB) produced by a higher-level cate- 
gory tree in a device revocation process. 
[0212] In the specific example shown in Fig. 37 : in re- 
sponse to receiving a renewed sub-EKB from a lower- 
level category tree shown in Fig. 37(a) including a de- 

20 vice to be revoked, a higher-level category tree produc- 
es a renewed EKB. The top node of the lower-level cat- 
egory tree including the device to be revoked corre- 
sponds to an endpoint node (node 1 00) 3601 of the high- 
er-level category tree. 

25 [0213] The higher-level category tree renews node 
keys at nodes in the path from the sub-root of the higher- 
level category tree to the endpoint node (node 100) 
3601 and produces a renewed sub-EKB so as to reflect 
the renewed node keys. The resultant renewed 

30 sub-EKB is shown in Fig. 37(b). In Fig. 37(b), the re- 
newed keys are underlined and primed. As described 
above, the node keys in the path from the renewed end- 
point node to the sub root are renewed, and the renewed 
sub-EKB of the category tree is produced so as to reflect 

35 the renewal of the node keys. 

[021 4] Now, revocation of a category tree is described 
below. 

[0215] Fig. 38(a) shows an example of a key distribu- 
tion tree structure managed on the basis of units of cat- 

40 egory trees. In this specific example, A root node is dis- 
posed at the top of the tree, and category trees A01 to 
Ann are disposed at a certain level below the root node. 
Category trees B01 to Bnk are disposed at a lower level, 
and category trees C1 to Cn are disposed at a further 

45 lower level. Category trees at the lowest level have end- 
point nodes (leaves) assigned to respective devices 
such as a recording/playjng-back apparatus and a play- 
back apparatus. 

[0216] Herein, it is assumed that a category tree Cn 
so (3730) should be revoked. The category tree Cn (3730) 
at the bottom includes a top node 3431 as shown in Fig. 
38(b), and a plurality of devices are assigned to respec- 
tive leaves at the endpoint nodes. 
[0217] By revoking the category tree Cn (3730), it is 
55 possible to remove all devices belonging to the category 
tree Cn (3730) from the tree structure at the same time. 
Revocation of the category tree Cn (3730) is performed 
by a category tree Bnk (3720) located nextto, at a higher 
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level, to the category tree Cn (3730). The category tree 
Bnk (3720) includes, as one of endpoint nodes, the top 
node 3731 ot the category tree Cn (3730). 
[0218] In order to revoke the lower-level category tree 
Cn (3730), the category tree Bnk (3720) renews an end- 5 
point node 3731 of the category tree Bnk (3720) corre- 
sponding to the lop node 3731 of the category tree Cnk 
(3730) and further renews node keys in the path from 
the category tree 3730 to be revoked to the sub root of 
the category tree Bnk (3720). The category tree Bnk 
(3020) then produces an enabling key block serving as 
a renewed sub-EKB. Herein, the node keys to be re- 
newed are node keys in the path from the sub root 3721 
shown in Fig. 38(c) to an endpoint node 3731 that is also 
the top node of the category tree to be revoked. More 
specifically, node keys assigned to nodes 3721 , 3724, 
3725, and 3731 are renewed. After renewing the node 
keys corresponding to these nodes, the category tree 
Bnk (3720) produces its renewed sub-EKB so as to re- 
flect the renewed node keys. 

[0219] Alternatively, when the category tree Bnk 
(3720) revokes the lower-level category tree Cn (3730), 
the category tree Bnk (3720) may not renew its endpoint 
node 3731 corresponding to the top node 3731 of the 
category tree Cnk 3730, but the category tree Bnk 
(3720) may renew only the other node keys in the path 
from the category tree 3730 to be revoked to the sub 
root of the category tree Bnk 3720 and may produce an 
enabling key block serving as a renewed sub-EKB. 
[0220] The renewed enabling key block (sub-EKB) 
produced by the category tree Bnk (3720) is transmitted 
to a higher-level category tree. In this specific case, the 
higher-level category tree is a category tree Ann (3710) 
which includes, as one of endpoint nodes, the top node 
3721 of the category tree Bnk (3720). 
[0221] If the category tree Ann (3710) receives the en- 
abling key block (sub-EKB) from the lower-level catego- 
ry tree Bnk (3720), the category tree Ann (371 0) replac- 
es the key assigned to the endpoint node 3721 of the 
category tree Ann (371 0) corresponding to the top node 
3721 of the category tree Bnk (3720) with the renewed 
key included in the enabling key block received from the 
lower-level category tree Bnk (3720), and the category 
tree Ann (3710) renews its own sub-EKB. Fig. 38(d) 
shows the tree structure of the category tree Ann (371 0). 
In the category tree Ann (3710) shown in Fig. 38(d), it 
is needed to renew node keys assigned to nodes 3711 , 
3714, and 3715 in a path from the sub-root 3711 to the 
endpoint node 3721 connected to the category tree that 
has transmitted the renewed sub-EKB. After renewing 
the node keys corresponding to these nodes, the cate- 
gory tree Ann (371 0) produces its renewed sub-EKB so 
as to reflect the renewed node keys. 
[0222] The above-described process is performed for 
further higher-level category trees until the root category 
tree shown in Fig. 30(b) has been renewed. Via the se- 
quence of processes described above, revocation of the 
category tree is completed. The renewed sub-EKB's 



produced by the respective category trees are finally 
transmitted to the key distribution center (KDC) and 
stored therein. The key distribution center (KDC) pro- 
duces various EKB's on the basis of all renewed 
sub-EKB's. Each renewed EKB has a form of an en- 
crypted key block that cannot be decrypted by any de- 
vice belonging to the revoked category tree. 
[0223] The sequence of category tree revocation 
processes is shown in Fig. 39. In the sequence shown 
in Fig. 39, a category tree management category tree 
(E -En), which wants to revoke some category tree, per- 
forms key renewal needed to isolate an endpoint node 
to be revoked from the category tree management cat- 
egory tree (E-En) and produces a renewed sub-EKB(E) 
of the category tree management category tree (E-En). 
The renewed sub-EKB(E) is transmitted to a higher-lev- 
el category tree. Upon receiving the renewed sub-EKB 
(E), the higher-level (parent) category tree (P1-En) re- 
news the node key assigned to the endpoint node cor- 
responding to the renewed top node of the renewed 
sub-EKB(E) and also node keys assigned to nodes in 
the path from that endpoint node to the sub-root, and 
then produces a renewed sub-EKB(P1 ) so as to reflect 
the renewed node keys. The above-described process 
is performed for further higher-level category trees, and 
all renewed sub-EKB's that are finally obtained are 
stored in the key distribution center (KDC) and managed 
thereby The key distribution center (KDC) produces 
various EKB's on the basis of all renewed sub-EKB's. 
Each renewed EKB has a form of an encrypted key 
block that cannot be decrypted by any device belonging 
to the revoked category tree. 

[0224] Fig. 40 illustrates the correspondence be- 
tween a revoked lower- level category tree and a higher- 
level category tree that revoked the lower- level category 
tree. An endpoint node 3901 of the higher-level category 
tree is renewed in response to revoking the category 
tree, and then the node keys in the path from the end- 
point node 3901 to the sub root of the higher- level cat- 
egory tree are renewed. Furthermore, a new sub-EKB 
is produced such that the renewal of the node keys is 
reflected. As a result, the node key of the top node 3902 
of the revoked lower-level category tree and the node 
key of the endpoint node 3901 of the higher-level cate- 
gory tree become different from each other. Because 
any EKB produced by the key distribution center (KDC) 
after the revocation of the category tree is based on the 
key of the endpoint node 3901 renewed by the higher- 
level category tree, any device corresponding to a leaf 
of the lower-level category tree cannot have the re- 
newed key and thus cannot decrypt the EKB produced 
by the key distribution center (KDC). 
[0225] Although in the example described above, a 
category tree at the bottom level that manages devices 
is revoked, a category tree that is located at a middle 
level and that manages a lower-level category tree may 
also be revoked by a category tree located next to, at a 
higher level, the category tree to be revoked in a similar 
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manner as described above. By revoking an entity man- 
agement category tree at a middle level, it is possible to 
simultaneously revoke all lower-level category trees and 
devices belonging directly or indirectly to the revoked 
category tree. 

[0226] As described above, revocation of a category 
tree makes it possible to perform revocation more easily 
than in the case where revocation is performed in units 
of devices. 

[Management of capability of category tree] 

[0227] When keys are distributed on the basis of cat- 
egory trees, the capability of each entity may be man- 
aged and a content may be distributed depending on 
the capability as described below. Herein, the term ca- 
pability is used to represent or define what kinds of con- 
tents or program a device can deal with. Examples of 
capabilities are a capability of decompressing audio da- 
ta compressed according to a specific compression 
scheme, a capability of audio reproduction according to 
a specific scheme, and a capability of dealing with a par- 
ticular image processing program. 
[0228] Fig. 41 shows an example of a category tree 
structure including capability definition information, A 
root node is disposed at the top of the key distribution 
tree structure, and a plurality of category trees in the 
form of a binary tree are disposed at lower levels. For 
example, a category tree 4001 is defined as having an 
audio playback capability according to any one of audio 
playback schemes A, B, andC. More specifically, for ex- 
ample, when music data compressed by an audio com- 
pression program A, B, or C is distributed, any device 
belonging to category trees belonging as lower-level 
category trees to the category tree 4001 can decom- 
press the compressed data. 

[0229] Similarly, a category tree 4002 is defined as 
having audio playback capability according to one of au- 
dio playback schemes B and C, a category tree 4003 is 
defined as having audio playback capability according 
to one of audio playback schemes A and B, a category 
tree 4004 is defined as having audio playback capability 
according to the audio playback scheme B, and a cate- 
gory tree 4005 is defined as having audio playback ca- 
pability according to the audio playback scheme C. 
[0230] On the other hand, a category tree 4021 is de- 
fined as having a video playback capability according to 
any one of schemes p, q, and r, a category tree 4022 is 
defined as having a video playback capability according 
to any one of schemes p and q, and a category tree 4023 
is defined as having a video playback capability accord- 
ing to the scheme p. 

[0231] The capability information of respective cate- 
gory trees is managed by the key distribution center 
(KDC). For example, when a certain content provider 
wants to distribute music data compressed by a specific 
compression program to various devices, the key distri- 
bution center (KDC) produces an enabling key block 



(EKB) that can be decrypted only by devices capable of 
playing back music data compressed by that specific 
compression program, on the basis of the capability in- 
formation of the respective category trees. The content 

5 provider encrypts a content key the enabling key block 
(EKB) produced in accordance with the capability infor- 
mation and distributes the resultant encrypted content 
key. The content provider also provides compressed 
music data encrypted using the content key to devices. 

10 This makes it possible to securely provide a specific 
processing program only to devices capable of process- 
ing the data. 

[0232] In the example shown in Fig. 41 , capability in- 
formation is defined for all category trees. However, it is 

15 not necessarily needed to define capability information 
for all category trees. For example, as shown in Fig. 42, 
capability information is defined only for lowest-level 
category trees directly related to devices, and capability 
information of devices belonging to the lowest-level cat- 

20 egory trees is managed by the key distribution center 
(KDC). Inthis case, in response to a request from acon- 
tent provider, the key distribution center (KDC) produces 
an enabling key block (EKB) that can be decrypted only 
by devices having a capability specified by the content 

25 provider, on the basis of the capability information de- 
fined for the lowest-level category trees. In the example 
shown in Fig. 42, capabilities are defined for category 
trees 4101 to 4105 whose endpoint nodes are related 
to devices, and the capabilities of respective category 

30 trees are managed by the key distribution center (KDC). 
For example, devices having an audio playback capa- 
bility according to the scheme B and having a video play- 
back capability according to the scheme r are related to 
the category tree 4101, and devices having an audio 

35 playback capability according to the scheme A and hav- 
ing a video playback capability according to the scheme 
q are related to the category tree 41 02. 
[0233] Fig. 43 shows an example of a capability man- 
agement table managed by the key distribution center 

40 (KDC). Fig. 43(a) shows the data format of the capability 
management table. A category tree ID is an identifier 
that identifies a category tree. A capability list indicates 
capabilities defined for a category tree indicated by a 
category tree ID. As shown in Fig. 43(b), the capability 

45 list consists of a plurality of bits each indicating whether 
various capabilities are available or not. For example, if 
the audio data playback capability according to scheme 
(A) is available, the corresponding bit is set to "1", but 
the bit is set to "0" if the capability is not available. Sim- 

50 iiarly, for the audio data playback capability according 
to scheme (B), the corresponding bit is set to "1 " if the 
capability is available, but the bit is set to "0" if the ca- 
pability is not available. Note that the method of setting 
the capability information is not limited to that described 

55 above, but another method may also be employed as 
long as the method can indicate the capabilities of the 
devices managed by the category trees. 
[0234] The capability management table further in- 
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eludes data representing the sub-EKB of each category 
tree. In a case where sub-EKB's are stored separately 
in another database, identification information of 
sub-EKB is described instead of the sub-EKB itself. Fur- 
thermore, the capability management table also in- 
cludes data indicating the sub root node of each cate- 
gory tree. 

[0235] On the basis of the capability management ta- 
ble, the key distribution center (KDC) produces an ena- 
bling key block (EKB) that can be decrypted only by de- 
vices having a capability of playing back a specific con- 
tent. Referring to Fig. 44, the process of producing the 
enabling key block on the basis of the capability infor- 
mation is described below. 

[0236] First, in step S4301 , the key distribution center 
(KDC) selects a category tree having a specified capa- 
bility from the capability management table. More spe- 
cifically, for example, when a content provider wants to 
distribute audio data according to the audio data play- 
back scheme A, the key distribution center (KDC) 
searches the capability list shown in Fig. 43(a) and se- 
lects category trees having a value of "1" in the bit indi- 
cating the audio data playback capability according to 
the. scheme A. 

[0237] Then in step S4302, the key distribution center 
(KDC) produces a list of IP's of selected category trees. 
Thereafter, in step S4303, the key distribution center 
(KDC) selects a path that should be included in a tree 
formed by selected category trees indicated by the ID's 
(that is, a path to be included in a key distribution tree). 
In step S4304, it is determined whether all paths includ- 
ed in the selection category tree ID's have been select- 
ed. If all paths have not been selected, paths are select- 
ed in step 4303 until all paths have been selected. That 
is, in the case where a plurality of category trees are 
selected, paths corresponding to the respective catego- 
ry trees are sequentially selected. 
[0238] If all paths included in the selected category 
tree ID's have been selected, the process proceeds to 
step S4305. In step S4305, a key distribution tree struc- 
ture including only the selected category trees is pro- 
duced. 

[0239] Then in step S4306, node keys included in the 
tree structure produced in step S4305 are renewed, 
thereby producing renewed node keys. Furthermore, 
sub-EKB's of the selected category trees included in the 
key distribute tree structure are extracted from the ca- 
pability managementtable. On the basis of the extracted 
sub-EKB's and the renewed node keys produced in step 
S4306, an enabling key block (EKB) is produced such 
that it can be decrypted only by the devices included in 
the selected category trees. The enabling key block 
(EKB) produced in the above-described manner can be 
used only by the devices having the specified capability, 
that is, the enabling key block (EKB) can be decrypted 
only by such devices. If, for example, a content key is 
encrypted using this enabling key block (EKB) and a 
content compressed by a specific program is encrypted 



using that content key, and if the resultant encrypted 
content key and content are provided to devices, then 
only the devices having the specific capability selected 
by the key distribution center (KDC) can use the content. 

5 [0240] As described above, the key distribution center 
(KDC) produces an enabling key block (EKB) that can 
be decrypted only by devices having capability of play- 
ing back a specific content, on the basis of the capability 
managementtable. Thus, when a new category tree is 

10 registered, it is needed to acquire capability information 
of the new category tree to be registered. The method 
of notification of the capability in the new category tree 
registration process is described below with reference 
to Fig. 45. 

15' [0241] Fig. 45 shows a capability notification se- 
quence performed when a new category tree is added 
to the key distribution tree structure. 
[0242] A new (child) category tree (N-En) to be added 
to the tree structure issues a new registration request to 
an upper-level (parent) category tree (P-En). Each cat- 
egory tree has its own public key according to the public 
key cryptography scheme. When the new category tree 
issues the registration. request, it transmits its public key 
to the upper-level category tree (P-En). 
[0243] Upon receiving the registration request, the 
upper-level category tree (P-En) transfers the received 
public key of the new (child) category tree (N-En) to a 
certificate authority (CA) to receive a public key of the 
new (child) category tree having a signature of the CA. 
The above procedure is performed in mutual authenti- 
cation between the upper-level category tree (P-En) and 
the new (child) category tree (N-En). 
[0244] If the authentication of the category tree re- 
questing for new registration is completed via the above 
35 process, the upper-level category tree (P-En) gives per- 
mission of the registration of the new (child) category 
tree (N-En) and transmits a node key assigned to the 
new (child) category tree to the new (child) category tree 
(N-En). This node key corresponds to one of endpoint 
40 nodes of the upper-level category tree (P-En), and also 
corresponds to the top node or a sub-root key of the new 
(child) category tree (N-En). 

[0245] After the completion of the transmission of the 
node key, the new (child) category tree (N-En) builds a 

45 tree structure of the new (child) category tree (N-En) and 
sets the received sub-root key at the top node of the tree 
structure. Furthermore, keys are set at the respective 
nodes and leaves, and an enabling key block (sub-EKB) 
associated with the category tree is produced. On the 

so other hand, the upper-level category tree (P-En) produc- 
es a sub-EKB associated with the upper- level category 
tree (P-En) such that an endpoint node, which was 
made active when the new (child) category tree (N-En) 
was connected thereto, is reflected in the sub-EKB. 

55 [0246] If the production of the sub-EKB including the 
node keys and leaf keys of new (child) category tree 
(N-En) is completed, the new (child) category tree 
(N-En) transmits the produced sub-EKB to the upper- 
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level category tree (P-En). Furthermore, the new (child) 
category tree (N-En) transmits the capability information 
of devices managed by the category tree to the upper- 
level category tree. 

[0247] Upon receiving the sub-EKB and the capability 
information from the new (child) category tree (N-En), 
the upper-level category tree (P-En) transfers the re- 
ceived sub-EKB and capability informationtcgether with 
a renewed sub-EKB of the upper-level category tree 
(P-En) to the key distribution center (KDC). 
[0248] The key distribution center (KDC) registers the 
received sub-EKB and capability information of the cat- 
egory tree into the capability management table de- 
scribed above with reference to Fig. 43, thereby obtain- 
ing an updated capability management table. On the ba- 
sis of the renewed capability management table, the key 
distribution center (KDC) can produce an EKB in various 
manners. For example, the EKB can be produced such 
that only a specified category tree or a specified device 
can decrypt the EKB. 

[Management of EKB using EKB type definition list] 

[0249] Now, when an EKB is produced such that it can 
be decrypted byoneormore selected category trees 
and the resultant EKB is provided such that it can be 
used in common by devices belonging to the respective 
selected category trees, a method of using an EKB type 
definition list indicating which category tree can use or 
decrypt the EKB is described below. 
[0250] In the present embodiment, if the key distribu- 
tion center (KDC) receives an EKB issue request from 
an EKB requester, such as a content provider, who 
wants the key distribution center (KDC) to issue an EKB 
to be used by the EKB requester, the key distribution 
center (KDC) produces an EKB on the basis of an EKB 
type identification number indicating the EKB type de- 
scribed in an EKB type definition list included in the re- 
ceived EKB issue request, such that the resultant EKB 
can be processed (decrypted) by the one or more cate- 
gory trees. 

[0251] In the process of producing the EKB, in accord- 
ance with top node identifiers of the respective category 
trees set in correspondence with the EKB type identifi- 
cation number described in the EKB type definition list, 
the key distribution center (KDC) requests the top-level 
category entities (TLCE), which are category tree man- 
gers, to produce their sub-EKB. If the sub-EKB's pro- 
duced by the respective TLCE's are received, the key 
distribution center (KDC) combines the received 
sub-EKB's into an EKB that can be processed by the 
category trees. 

[0252] In the present embodiment, the EKB requester 
such as the content provider (CP) can select specific 
category trees on the basis of the EKB type definition 
list. After the EKB requester such as the content provid- 
er (CP) selected specific category trees on the basis of 
the EKB type definition list, EKB requester requests the 



key distribution center (KDC) to issue an EKB that can 
be processed by the selected specific category tree. In 
response to the EKB request, the key distribution center 
(KDC) requests the management entity of the selected 

5 category tree to issue a sub-EKB. The management en- 
tity of each selected category tree produces an EKB that 
can be process only by devices of that management en- 
tity other than revoked devices and transmits the result- 
ant EKB to the key distribution center (KDC). The key 

10 distribution center (KDC) combines the one or more 
sub-EKB's thereby producing an EKB that can be proc- 
essed only by the category trees selected by the EKB 
requester and provides the resultant EKB to the EKB 
requester. Upon receiving the EKB from the key distri- 

15 bution center (KDC), the EKB requester produces an 
encrypted key or encrypted content that can be decrypt- 
ed only by using a key acquired by processing the EKB 
and distributes the resultant encrypted key or content. 
[0253] First, various entities in the system are de- 

20 scribed briefly. 

Key distribution center (KDC) 

[0254] A key distribution center (KDC) issues ena- 
25 bling key blocks (EKB) and manages an EKB type def- 
inition list associated with the issued EKB's. 
[0255] Top level category entity (TLCE) <> A top level 
category entity (TLCE) is an entity which manages a cat- 
egory tree, such as a format holder of a recording de- 
30 vice, which manages a category tree. The TLCE man- 
ages the category tree, produces a sub-EKB that can 
be processed (decrypted) by devices within the catego- 
ry tree managed by the TLCE, and provides the result- 
ant sub-EKB to the key distribution center (KDC). 

35 

EKB requester 

[0256] An EKB requester is, for example, an entity 
such as a content provider that provides, as electronic 

40 content distribution (ECD) service, various contents 
such as video data, audio data, or programs. Another 
example of an EKB requester is a format holder of a stor- 
age medium. The content provider provides an encrypt- 
ed content, key, or medium that can be decrypted using 

45 a key which can be acquired by processing an EKB 
which is issued by the key distribution center (KDC) in 
response to a request issued by the content provider. 
[0257] For example, the content provider (CP) en- 
crypts a content using a root key described in the EKB 

50 produced by the key distribution center (KDC) and dis- 
tributes the resultant encrypted content. The format 
holder of storage media distributes media after writing 
the EKB onto the storage media during the production 
thereof so that a content encrypted using a root key of 

55 the EKB can be stored thereon. 
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(TLCE and category-based tree management) 

l 

[0258] The category-based tree management has 
been already described above. Herein, the relationship 
between the top-level category entity (TLCE) and the 
category tree is described with reference to Fig. 46. 
[0259] As described above, each category is a set of 
devices having similar features. More specifically, an ex- 
ample of a category is a set of devices produced by the 
same manufacturer. Another example is a set of devioes 
that can deal with a specific encoding format. In Fig. 46, 
A, B, C, and D denote category trees. 
[0260] In Fig. 46, a root tree at the top has a tree struc- 
ture having, for example, eight levels (eight node levels). 
Top nodes of respective category trees are disposed at 
the bottom of the root tree. The category trees may be 
related to each other such that a certain category tree 
is higher in level than another category tree. In the spe- 
cific example shown in Fig. 46, category trees C and D 
are related to each other wherein the category tree C is 
a higher-level category tree related to the category tree 
D at the lower level. 

[0261] Each category tree directly connected to the 
root tree at the top is referred to as a top-level category 
tree, and an entity that manages a top-level category 
tree is referred to as atop-level category entity (TLCE). 
In the specific example shown in Fig. 46, category trees 
A, B, and C are top-level categories, and entities that 
mange these top-level categories are top-level category 
entities (TLCE's). Each top-level category entity (TLCE) 
is basically responsible for managing all category trees 
including the top-level category tree itself and lower-lev- 
el category trees related to the top-level category tree. 
In the specific example shown In Fig. 46, the TLCE that 
manages the category tree C also manages the catego- 
ry tree D. If there is another category tree at a further 
lower level related to the category tree D, the TLCE that 
manages the category tree C also manages the further 
lower- level category tree. However, another category 
entity (sub category entity) may be established, and the 
responsibility and the right of management of the lower- 
level category tree D may be delegated to that sub cat- 
egory entity. 

[0262] Each device which uses a content, such as a 
recording/reproducing apparatus, is assigned by the 
top-level category entity (TLCE) to a leaf of a certain 
tree, and the device holds some of keys assigned to 
nodes in a path from that leaf to the root. A set of node 
keys held by one device is referred to as a device node 
key (DNK) set. The number of keys held by each device 
(the number of keys included in a DNK set) is deter- 
mined by the top-level category entity (TLCE). 
[0263] Fig. 47 shows the outline of processes per- 
formed among respective entities such as a key distri- 
bution center (KDC), a top-level category entity (TLCE), 
and an EKB requester. 

[0264] A key distribution center (KDC) 4511 is includ- 
ed in a management entity 4510 of a tree-based EKB 



distribution system. The management entity 4510 fur- 
ther includes a certificate authority (C A) 451 2 that writes 
a signature on each EKB. 

[0265] The key distribution center (KDC) 4511 man- 

s ages keys of subtrees such as top-level category trees. 
The key distribution center (KDC) 4511 also manages 
an EKB type definition list that will be described later 
and produces EKB's. The certificate authority (CA) 451 2 
writes a signature on each EKB produced by the key 

10 distribution center (KDC) and issues a public key corre- 
sponding to a secret key on which a signature is written, 
for use in verification of the signature, 
[0266] An EKB requester 4520 requests the key dis- 
tribution center (KDC) 451 1 to issue an EKB. The EKB 

15 requester may be a content provider (CP) who provides 
a content-stored medium such as a CD or DVD on which 
a content is stored, a content provider (CP) who distrib- 
utes a digital content, or a storage system licensor who 
provides a license of a format of a storage system such 

20 as a flash memory. 

[0267] Each EKB requester 4520 provides an EKB 
corresponding to a content, a medium, or a license for- 
mat such that a key needed in use of the content, the 
medium, orthe license format provided by EKB request- 

25 er can be extracted by processing the EKB. Each EKB 
is produced by the key distribution center (KDC) 4511 
in response to an EKB request sent to the key distribu- 
tion center (KDC) 4511 from the EKB requester 4520. 
[0268] If the EKB requester 4520 receives an EKB is- 

30 sued in response to the EKB request sent to the key 
distribution center (KDC) 451 1 , the EKB requester 4520 
may provide the EKB to a media manufacturers 4540 
and/or a device manufacturers 4550 and may provide a 
medium or a device, in which the EKB is stored, to a 

35 user. Each EKB is produced such that it can be proc- 
essed by one or more category trees. 
[0269] In the present system, the EKB's may be pro- 
duced in various fashions and may be used in various 
manners. For example, an EKB may be produced such 

40 that it can be process in common by a plurality of cate- 
gory trees (two or three category trees or a greater 
number of category trees), or may be produced such 
that it can be processed only one category tree. Various 
types of EKB's may be described in the form of a list in 

45 the EKB type definition list. The EKB type definition list 
is managed by the key distribution center (KDC). The 
EKB type definition list will be described in further detail 
later. The EKB requester 4520 can acquire the EKB type 
definition list by issuing a request for the EKB type def- 

50 inition list to the key distribution center (KDC) 4511. 
When data in the list is renewed, updated data is trans- 
mitted to the EKB requesters 4520 from the key distri- 
bution center (KDC) 4511 . 

[0270] As described above, the top-level category en- 
55 tities (TLCE's) 4530 are management entities of cate- 
gory trees directly connected to the root tree. Each top- 
level category entity (TLCE) 4530 manages keys of a 
subtree and a correspondence list representing the cor- 
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respondence between the device ID and the device 
node key (DNK) set, which is a set of node keys stored 
in each device for use in processing the EKB. The top- 
level category entity (TLCE) 4530 also produces a de- 
vice node key (DNK) set to be stored in a device of a 
Lype managed by the top-level category entity (TLCE) 
4530 and provides it to a manufacturer 4550 that pro- 
duces the device. 

[0271] If the key distribution center (KDC) 4511 re- 
ceives an EKB request from the EKB requester 4520, 
the key distribution center (KDC) 4511 produces an EKB 
in accordance with the EKB request. For example, in a 
case where the EKB request specifies that the EKB can 
be processed by two specific top-level category trees, 
the key distribution center (KDC) 4511 requests those 
two top-level category entities (TLCE's) 4530 to issue 
their sub-EKB's. Upon receiving the sub-EKB request, 
each top-level category entity (TLCE) 4530 produces a 
sub-EKB that can be used by an authorized device with- 
in the category tree to acquire the root key and transmits 
the resultant sub-EKB to the key distribution center 
(KDC) 451 1 . On the basis of the one or more sub-EKB's 
received from the TLCE's the key distribution center 
(KDC) 4511 produces an EKB. The process of produc- 
ing the EKB on the basis of the sub-EKB's will be de- 
scribed in detail later. 

[0272] The top-level category entities (TLCE's) 4530, 
as with the EKB requesters 4520, can acquire the EKB 
type definition list by sending a request for it to the key 
distribution center (KDC) 4511 . 

[0273] Each top-level category entity (TLCE) 4530 
can also request the key distribution center (KDC) 451 1 
to delete EKB type definition data associated with the 
top-level category entity (TLCE) 4530 from the EKB type 
definition list. For example, the delete request may 
specify that an EKB type defined as can be shared by 
another category tree should be deleted from the list. In 
a case wh ere a tree managed by the a top-level category 
entity (TLCE) 4530 is renewed, the top-level category 
entity (TLCE) 4530 sends a renewal notification to the 
key distribution center (KDC) 4511. The detailed proc- 
ess thereof will be described later with reference to a 
flow chart. 

[0274] The device manufacturers 4550 can be classi- 
fied into two types. Device manufacturers of one type 
are DNKE device manufacturers 4551 which produce 
devices in which both a device node key (DNK) set and 
an EKB are stored. Device manufacturers of the other 
type are DNK device manufacturers 4552 which pro- 
duce devices in which only a device node key (DNK) set 
is stored. 

[0275] Fig. 48 illustrates, in the form of a bock dia- 
gram, examples of configurations of the key distribution 
center (KDC), the EKB request and the top-level cate- 
gory entity (TLCE) shown in Fig. 47. The key distribution 
center (KDC), the EKB requester, and the top-level cat- 
egory entity (TLCE) are information processing appara- 
tuses having an encrypted-data communication capa- 



bility, which are constructed so as to serve as an EKB 
distribute apparatus, an EKB requesting apparatus, and 
a category tree management apparatus. 
[0276] The information processing apparatus of each 

5 entity includes a cryptographic unit responsible for gen- 
eral cryptographic process in mutual authentication with 
another entity and in data communication. The crypLo- 
graphic unit includes a control unit for generally control- 
ling the cryptographic process associated with authen- 

10 tication, encryption, and decryption. An internal memory 
of the cryptographic unit serves to store data such as 
key data and identification data needed in various proc- 
essed such as mutual authentication, encryption, and 
decryption. The identification data is used, for example, 

15 in mutual authentication with another entity. 

[0277] An encryption/decryption unit performs, in data 
transmission using key data stored in the internal mem- 
ory, authentication, encryption, decryption, data verifi- 
cation, and random number generation. 

20 [0278] As for the information processing apparatus 
serving as the EKB requester, it may also be configured 
such that a key is not generated by the EKB requester. 
In this case, components used to generate the key, such 
as a random number generator, are not necessary. More 

25 specifically, in a case where the information processing 
apparatus serving as the EKB requester generates a 
root key to be included in an EKB and requests the key 
distribution center to generate the EKB so as to include 
the root key, the information processing apparatus has 

30 to include means for generating the root key. However, 
in a case where the information processing apparatus 
serving as the EKB does not produce the root key to be 
included in the EKB, but requests the key distribution 
center (KDC) to produce the root key and further pro- 

35 duce the EKB including the root key produced by the 
key distribution center (KDC), the information process- 
ing apparatus does not need to include components 
such as the random number generator used to produce 
the key. 

40 [0279] Because information such as an encryption 
key is stored in the internal memory of the cryptographic 
unit, the internal memory should be constructed such 
that an unauthorized access to the memory is prevent- 
ed. More specifically, the cryptographic unit is config- 

45 ured using an anti-tamper memory formed of a semicon- 
ductor chip or the like so as to be protected from an ex- 
ternal access. 

[0280] Each entity includes, in addition to the crypto- 
graphic unit described above, a CPU (Central Process- 

so ing Unit), a RAM (Random Access Memory), a ROM 
(Read Only Memory), an input unit, a display unit, a da- 
tabase interface, and a database. 
[0281] The CPU (Central Processing Unit), the RAM 
(Random Access Memory), and the ROM (Read Only 

55 Memory) form a control system of the entity. The RAM 
is used a main memory used by the CPU as a work area 
in various processes. The ROM is used to store a start- 
ing program executed by the CPU. 
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[0282] The database or storage means of each infor- 
mation processing apparatus stores data managed by 
the entity. For example, in the key distribution center 
(KDC), management data associated with issued EKB's 
and the EKB type definition list are stored in its data- s 
base. In the case of the top-level category entity (TLCE) , 
management data associated with devices belonging to 
the category tree, such as data indicating correspond- 
ence between the devices managed by the TLCE and 
the device node key (DNK) sets, is stored in the data- 
base. In the EKB requester, the database stores man- 
agement data indicating the correspondence between 
contents provided by the EKB requester and the EKB's 
used for the contents and management data indicating 
the devices to which the contents are provided. It is de- 
sirable that the EKB type definition list be stored in an 
accessible manner also in the information processing 
apparatuses serving as the EKB requester and the top- 
level category entity (TLCE). Alternatively the EKB type 
definition list may be stored at a Web site that is man- 
aged by the key distribution center (KDC) and that can 
be accessed by the EKB requester and the top-level cat- 
egory entity (TLCE). 

[0283] As described earlier, devices use a device 
node key (DNK) set when processing (decrypting) an 
EKB. An example of a device node key (DNK) set stored 
in a device is described below with reference to Fig. 49. 
In Fig. 49, a tree nodes a category tree, in which leaves 
related to devices are disposed at the bottom. For ex- 
ample, the tree may be that managed by a top-level cat- 
egory entity (TLCE). The category tree is connected to 
a root tree (having an eight-level structure, for example) 
located at a higher level. Each device holds node keys 
assigned to nodes in a path from the device to a higher 
level, as shown in Fig. 49. These keys are held as a 
device node key (DNK) set in the device so that an EKB 
can be decrypted using the device node key (DNK) set: 
[0284] Basically, each device is assigned to one leaf 
such that there is no overlap. 

[0285] However, in an exceptional case in which soft- 
ware programs such as PC programs are related to 
leaves, a version of software package may be assigned 
to all leaves. The assignment of devices is determined 
by the TLCE. That is, the TLCE determines which device 
is assigned to which leaf, and which node keys are as- 
signed to which device. 

[0286] The top-level category entity (TLCE) may be a 
device supplier (manufacturers). In this case, the top- 
level category entity (TLCE) may supply (sell) a device 
after storing a device node key (DNK) set therein. That 
is, it is possible to supply (sell) a device such as a re- 
cording/reproducing apparatus including a memory in 
which node keys of a specific category tree have been 
stored as a device node key (DNK) set. 

(EKB type definition list) 

[0287] Distribution of an EKB on a category basis has 



already been described. In a case where an EKB for 
common use by a plurality of categories is issued, that 
is, in a case where the issued EKB can be process by 
devices belonging to different category trees, there is a 
possibility that some problems occur. 
[0288] For example, let us assume herein that two dif- 
ferent companies A and B have a license of a format of 
a rewritable medium (storage medium) such as a port- 
able flash memory; a manufacturer having a license of 
a medium (portable flash memory) is an entity of a top 
level category; and category trees managed by compa- 
nies A and B, respectively, exist at a level below the top- 
level category. Let us further assume that, in order that 
devices of companies A and B be compatible with each 
other and can use various contents in common, an EKB 
that can be processed (decrypted) by devices belonging 
to any one of the category trees of companies A and B 
is produced and distributed by the key distribution center 
(KDC). 

[0289] In such a situation, if secrecy of a device node 
key (DNK) set of one device belonging to a category tree 
managed by the company A is broken, there is a possi- 
bility that all already-distributed contents, which can be 
used by devices of both companies A and B by using 
that device node key (DNK) set, may be used in an un- 
authorized manner. To prevent such unauthorized use, 
it is needed to renew the EKB for evocation. However, 
in this case, because the EKB has been produced such 
that it can be used in common by the two category trees 
associated with companies A and B, revocation should 
be performed not only for the category tree associated 
with company A but for both categories associated with 
companies A and B. 

[0290] As described above, in the case where an EKB 
is distributed such that it can be used in common by a 
plurality of category trees, renewal of the EKB and rev- 
ocation should be performed not only for one category 
tree but for all category trees that use in common the 
EKB. As a result, company B is influenced by a category 
tree other than the category tree managed by company 
B. This results in an increase in complexity of manage- 
ment process. 

[0291] Herein, a technique of solving the above prob- 
lem is disclosed below. That is, the right of giving per- 
mission of issuing an EKB usable in common by a plu- 
rality of categories is granted to the respective category 
entities that manage the categories. Issuing of an EKB 
for common use is permitted by an entity only when the 
entity can accept a risk of a problem which may occur 
in devices of a category of an entity as a result of occur- 
rence of a problem in a device belonging to another cat- 
egory. However, in a case where the entity cannot ac- 
cept the risk T the entity does not permit issue or use of 
a common EKB. 

[0292] In this method, various kinds of EKB's are pro- 
duced and used. For example, an EKB may be such an 
EKB that can be processed by two or three category 
trees, or a greater number of category trees . but another 
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EKB may be such an EKB that can be processed only 
by a single category tree. An EKB type definition list is 
used to describe such various types of EKB's in the form 
of a list. Fig. 50 shows an example of an EKB type def- 
inition list. The EKB type definition list is stored and man- 5 
aged by the key distribution center (KDC) . The EKB type 
definition list is provided to, or can be accessed by, EKB 
requesters or TLCE's, as required. 
[0293] As shown in Fig. 50, the EKB type definition 
list includes fields of "EKB type identification number", 
"node", and "description". The "EKB type identification 
number" is a number identifying a specific one of various 
EKB's listed in the EKB type definition list. If the identi- 
fication number is different, then the category tree orthe 
combination of category trees that allowed to process 
the EKB become different. 

[0294] The "node" field is used to describe the top- 
node ID of category trees to which a specific EKB can 
be applied. For example, for an EKB of an EKB type 
identification number of 1 , the top-node ID of a category 
t r ee associated with an MS (Memory Stick) is assigned. 
On the other hand, for an EKB of a row of an EKB type 
identification number of 3, the top-node ID of the cate- 
gory tree associated with the MS (Memory Stick) and 
the top-node ID of a category associated with a PHS are 
assigned. 

[0295] The field of "description" is used to store de- 
scriptions of various types EKB's listed in the EKB type 
definition list. For example, the data in the "description" 
field for the EKB of the EKB type identification number 
of 1 indicates that this EKB is for the MS (Memory Stick), 
and the data in the "description" field for the EKB of the 
EKB type identification number of 3 indicates that this 
EKB can be used in common by category trees of the 
MS (Memory Stick) and the PHS. 
[0296] The EKB type definition list shown in Fig. 50 is 
managed by the key distribution center (KDC). An entity 
such as .a content provider, which is going to distribute 
encrypted data such as an encrypted key or an encrypt- 
ed content encrypted using a key that can be extracted 
by processing the EKB, selects, from the EKB type def- 
inition list shown in Fig. 50, an EKB type that can be 
processed by a category including devices to which the 
content is going to be supplied. The content provider 
then requests the key distribution center (KDC) to pro- 
duce an EKB specified by the corresponding EKB type 
identification number. 

[0297] When various types of EKB's are registered in 
the EKB type definition list, registration should be per- 
formed with the approval of the top-level category enti- 
ties (TLCE's) of the category trees to be registered. 
When, forexample,TLCE-A of the category tree refused 
issue of an EKB shared by another category, an EKB 
type that is shared by the category tree A and said an- 
other category is not registered in the EKB type defini- 
tion list. 

[0298] In acase where allTLCE-Aof the category tree 
A ( TLCE-B of the category tree B, and TLCE-C of the 



category tree C, have approved issue of an EKB for 
common use, an EKB type that can be process in com- 
mon by those three category trees is registered in the 
EKB type definition list. Thereafter, a content provider 
can specify the EKB type identification number assigned 
to that EKB type and can request the key distribution 
center (KDC) to issue a corresponding EKB. 
[0299] That is, in order to register a new EKBtype and 
a corresponding EKB type identification number in the 
EKB type definition list, the following process is re- 
quired. 

(1 ) All TLCE's, which manage categories relating to . 
an EKB type having an EKB type identification 
number to be registered, send an EKB type regis- 
tration request to the key distribution center (KDC). 

(2) The key distribution center (KDC) confirms that 
the EKB type registration requests have been re- 
ceived from all top-level category entities (TLCE's) 
of category trees which will be able to an EKB of the 
EKB type requested to be registered. After the con- 
firmation, the key distribution center (KDC) defines 
a new EKB type identification number for the EKB 
type and adds it to the EKB type definition list. 

(3) The key distribution center (KDC) sends an EKB 
type definition list renewal notification to all TLCE's 
and EKB requesters to notify that the EKBtype def- 
inition list has been renewed. 

[0300] The EKB type definition list is opened for use 
by all TLCE's and EKB requesters by sending it to all 
TLCE's and EKB requesters or by putting it at a Web 
site. Thus, TLCE's and EKB requesters can acquire 
EKB type information described in the newest EKB type 
definition list. 

(EKB type registration) 

[0301] A process performed by the key distribution 
center (KDC) before registering a new EKB type in the 
EKBtype definition list is described below with reference 
to Fig. 51. First, the key distribution center (KDC) re- 
ceives an EKB type registration request from a TLCE 
that wants to register a new EKB type (S1 01 ). The EKB 
type registration request from the TLCE includes a de- 
scription of then umber of categories that should be able 
to use in common the EKB to be registered. The key 
distribution center (KDC) determines whether as many 
similar EKB type registration requests as the number of 
categories described in the request have been received 
from TLCE's (S102). If and only if as many EKB type 
registration requests as the number of categories de- 
scribed in the request have been received from TLCE's, 
the key distribution center (KDC) registers the new EKB 
type in the EKB type definition list in accordance with 
the request. The key distribution center (KDC) performs 
a list renewal process and issues a list renewal notifica- 
tion (S1 03). The renewal notification is sentto all TLCE's 
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and EKB requesters. 

[0302] As descried above, the key distribution center 
(KDC) performs registration of a new EKB type identifier 
into the EKB type definition list only when approval of 
the registration has been obtained from all category en- 
tities which manage the category trees specified as cat- 
egory trees which should be able to process the EKB 
type to be registered. 

[0303] In the above process, mutual authentication 
and encryption of transmission data are performed, as 
required, in communication between the key distribution 
center (KDC) and TLCE's or EKB requesters. Further- 
more, encryption of other messages, writing of signa- 
ture, and data verification may also be performed. In a 
case where authentication or cryptographic communi- 
cation is performed using the public key cryptographic 
technology, it is required that entities already have their 
public keys. 

(Revocation of an EKB type) 

[0304] When it is needed to revoke all devices belong- 
ing to a certain category, the top-level category entity 
(TLCE) issues a request for revocation of EKB types as- 
sociated with the category to the key distribution center 
(KDC). Furthermore, when a certain service is going to 
be terminated or when there is some reason, the top- 
level category entity (TLCE) may issue a re quest for rev- 
ocation of an EKB type from the present registration to 
the KDC. 

[0305] The process of revocation of an EKB type is 
described below with reference to a flow chart shown in 
Fig. 52. First, the key distribution center (KDC) receives 
an EKB type revocation request from a TLCE that wants 
to revoke an EKB type (S201). If the key distribution 
center (KDC) receives the EKB type revocation request 
from the TLCE, the key distribution center (KDC) con- 
firms that the issuer of the request is the TLCE that man- 
ages the category associated with the EKB type re- 
quested to be revoked. After confirmation, the key dis- 
tribution center (KDC) revokes, from the EKB type def- 
inition list, the EKB type identification number corre- 
sponding to the EKB type specified by the EKB type rev- 
ocation request, and performs renewal of the EKB type 
definition list. Thereafter, the key distribution center 
(KDC) issues a list renewal notification (S202). The re- 
newal notification is sent to all TLCE's and EKB request- 
ers. 

[0306] As described earlier, the key distribution center 
(KDC) performs revocation of an EKB type identifier reg- 
istered in the EKB type definition list, if and only if a rev- 
ocation request is received from at least one of category 
entities managing one or more category trees selected 
as category trees that can be processed on the basis of 
an EKB type requested to be revoked. In this case, ap- 
proval or the other category entities is not needed. 
[0307] In the above process, mutual authentication 
and encryption of transmission data are performed, as 



required, in communication between the key distribution 
center (KDC) and TLCE's or EKB requesters. Further- 
more, encryption of other messages, writing of signa- 
ture, and data verification may also be performed. In a 
5 case where authentication or cryptographic communi- 
cation is performed using the public key cryptographic 
technology, it is required that entities already have their 
public keys. 

10 (EKB type definition list renewal notification) 

[0308] For example, in a case where, in a certain cat- 
egory tree, the TLCE managing that category tree has 
performed some process resulting in a change in the 
15 state of the tree, such as revocation of a device or a 
change in a device node key (DNK) set stored in a cer- 
tain device into another device node key (DNK) set, the 
TLCE has to notify the EKB requesters or TLCE's using 
EKBs associated with that device of the fact that the 
20 process has been performed. 

[0309] When revocation of a device has been per- 
formed, if a notification of the revocation is not sent, a 
content provider (CP) may use an old EKB in transmis- 
sion of an encrypted content. The old EKB can be proe- 
ms essed (decrypted) even by the revoked device, and thus 
there is a possibility that unauthorized use of the content 
is continued. In a case where a device node key (DNK) 
set has been renewed, the old DNK replaced with the 
new one is usually discarded and a device has the new 
30 DNK. However, if a content provider does not use an 
EKB in which the new DNK is reflected, a device having 
the new DNK cannot process (decrypt) the EKB and 
thus cannot access the content. 
[0310] To avoid such a problem, a TLCE has to send 
35 a tree change notification to the key distribution center 
(KDC) when one of changes described below occurs. 

* A change in a tag part of an EKB performed in re- 
sponse to revocation of a device 
40 * A change in a value of a DNK set stored in at least 
one device, performed in response to renewal of a 
device node key (DNK) set 

[0311] The tree change notification includes informa- 
45 tion indicating an EKB type identification number to be 
changed in the EKB type definition list, information indi- 
cating a category associated with that EKB type identi- 
fication number, and information indicating what has oc- 
curred, for example, indicating that revocation or DNK 
50 renewal has been performed. 

[031 2] The process of EKB type definition list renewal 
notification is described below with reference to a flow 
chart shown in Fig. 53. First, the key distribution center 
(KDC) receives a tree change notification from a TLCE 
55 (S301 ). Upon receiving the tree change notification from 
the TLCE, the key distribution center (KDC) extracts an 
EKB type identification number associated with the cat- 
egory from the EKB type definition list, and sends an 
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EKB type definition list renewal notification to all TLCE's 
and EKB requesters to notify what kind of change (rev- 
ocation or DNK replacement) has occurred and which 
EKB type identification number is influenced by the 
change. In the above process, mutual authentication 
and encryption of transmission data are performed, as 
required, in communication between the key distribution 
center (KDC) and TLCE's or EKB requesters. Further- 
more, encryption of other messages, writing of signa- 
ture, and data verification may also be performed. In a 
case where authentication or cryptographic communi- 
cation is performed using the public key cryptographic 
technology, it is required that entities already have their 
public keys. 

(EKB type definition list request) 

[0313] In orderto obtain a newest version of EKB type 
definition list, a top-level category entity (TLCE), a sub- 
category entity (SCE) other than the TLCE, or an EKB 
requester such as a content provider may send a re- 
quest for the EKB type definition list to the key distribu- 
tion center (KDC). In response to the request, the key 
distribution center (KDC) returns the newest version of 
EKB type definition list to the requester. 
[0314] The EKB type definition list request process is 
described below with reference to a flow chart shown in 
Fig. 54. First, the key distribution center (KDC) receives 
an EKB type definition list from a TLCE, a sub-category 
entity, or an EKB requester (S401). Upon receiving the 
EKB type definition list, the key distribution center (KDC) 
extracts the newest version of EKB type definition list 
and transmits it to the entity which has issued the re- 
quest. In the above process, mutual authentication and 
encryption of transmission data are performed, as re- 
quired, in communication between the key distribution 
center (KDC) and TLCE's, sub-category entities, or EKB 
requesters. Furthermore, encryption of other messag- 
es, writing of signature, and data verification may also 
be performed. In a case where authentication or cryp- 
tographic communication is performed using the public 
key cryptographic technology, it is required that entities 
already have their public keys. 

(Issue of an EKB) 

[0315] An EKB is issued in response to an EKB re- 
quest received from an EKB requester. Specific exam- 
ples of EKB requesters are listed below. 

[a] Content provider (CP) that provides a content- 
stored medium such as a CD or DVD 

[b] Content provider that provides electronic content 
distribution (ECD) service 

[c] Holder of a storage system format 

[031 6] That is, the EKB requester is an entity that pro- 
vides a service, a medium, or a device in which a content 
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or aformat can be used by acquiring a key by decrypting 
an EKB. 

[0317] The storage system format holders described 
in [c] can be classified into two types as described below. 

5 

[c1] Formal.holder that provides an acquired EKB 
to a manufacturers of a storage medium according 
to a format in which the EKB is stored into the stor- 
age medium when it is produced. 
10 [c2] Format holder that provides an acquired EKB 
to a manufacturers of a recording device according 
to a format in which the EKB is stored into the re- 
cording device when it is produced. 

15 [0318] The EKB issue process is described below. 

(1) Production of a content key 

[0319] First, an EKB requester such as a content pro- 
20 vider produces a content key to be used in conjunction 
with a content, a device, or a medium the EKB requester 
provides. 

[0320] For example, in the case where the EKB re- 
quester is 

25 

[a] a content provider (CP) that provides a content- 
stored medium such as a CD or DVD, or 

[b] a content provider that provides electronic con- 
tent distribution (ECD) service, 

30 

the produced content key is used to protect the content 
stored on the medium or protect the content during the 
electronic content distribution (ECD) service. 
[0321] On the other hand, when the EKB requester is 

35 

[c1] a format holder that provides an acquired EKB 
to a manufacturers of a storage medium according 
to a format in which the EKB is stored into the stor- 
age medium when it is produced, 

40 

the content key is used to protect the content stored on 
the medium. 

[0322] In the case where the EKB requester is 

45 [c2] a format holder that provides an acquired EKB 

to a manufacturers of a recording device according 
to a format in which the EKB is stored into the re- 
cording device when it is produced, 

50 the content key is used to protect the content 

stored using the recording device.. 
[0323] The mechanism, such as a cryptographic al- 
gorithm, of protecting the content using/the content key 
may be determined arbitrarily for each format. 

55 

(2) Production of a root key 

[0324] The EKB requester produces a root key that 
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can be extracted by decrypting the EKB. Alternatively, 
the root key may be acquired from the key distribution 
center (KDC) instead of producing it. The root key is 
used to protect (encrypt) the content key. The mecha- 
nism, such as a cryptographic algorithm, of protecting 
the content key using the root key may be determined 
arbitrarily for each format. 

(3) Request for issue of an EKB 

[0325] The EKB requester sends an EKB issue re- 
quest to the key distribution center (KDC). 
[0326] The EKB issue request includes information in- 
dicating the root key and information specifying one of 
EKB type identification numbers registered in the EKB 
type definition list, to indicate a category including the 
device to which the root key is to be transmitted using 
the EKB. On the basis of the EKB type definition list 
stored in the storage medium of the EKB requester, or 
on the basis of the EKB type definition list acquired from 
a site on a network, the EKB requester selects an EKB 
type associated with a category including the device to 
which service such as providing of a content is to be 
provided. The EKB requester then sends to the key dis- 
tribution center (KDC) an EKB issue request including 
information specifying the EKB type identification 
number indicating the selected EKB type. 

(4) Issue of EKB 

[0327] In accordance with the EKB issue request re- 
ceived from the EKB requester, the key distribution cent- 
er (KDC) produces an EKB such that the EKB includes 
the root key if the root key is not included in the EKB 
issue request. However, if the EKB issue request does 
not include the root key and if the EKB issue request 
includes a request for production of the root key, the key 
distribution center (KDC) produces the root key and fur- 
ther produces an EKB including the produced root key. 
The resultant EKB is transmitted to the EKB requester. 
[0328] The EKB produced by the key distribution cent- 
er (KDC) can be of a type that can be processed only 
by a single category tree or of a type that can be proc- 
essed by a plurality of category trees. On the basis of 
the EKB type identification number specified in the EKB 
issue request, the key distribute center (KDC) extracts 
a category associated with the EKB type identification 
number, that is, extracts the node described in the node 
field, corresponding to the EKB type identification 
number, of the EKB type definition list. In the node field, 
the top node ID of the category is described. The entity 
managing that category can be known from this node 
ID. On the basis of the node ID, the key distribution cent- 
er (KDC) sends asub-EKB issue request to the top-level 
category entity (TLCE) that manages the category. The 
sub-EKB issue request includes information indicating 
the root key and information indicating the category. 
[0329] If the TLCE receives the sub-EKB issue re- 



quest from the key distribution center (KDC), the TLCE 
produces a sub-EKB such that devices (non-revoked 
devices) within specified one or more categories can fi- 
nally extract the root key from the sub-EKB, and the 
5 TLCE transmits the resultant sub-EKB to the key distri- 
bution center (KDC). 

[0330] The sub-EKB produced by the top-level cate- 
gory entity (TLCE) has a data structure similar to that of 
a usual EKB (Fig. 6) except that the version number and 

10 other information for verification (version check value) 
are not include. The algorithm of encrypting a higher- 
level node key or a root key using a leaf key or a lower- 
level node key described in the sub-EKB : the key length , 
and the mode may be arbitrarily determined for each 

15 TLCE (format holder) that produces the sub-EKB. This 
makes it possible to employ a particularsecurity scheme 
differently from the other formats. A default encryption 
algorithm may be determined. For example, the tri- 
ple-DES according to FIPS46-2 may be employed as 

20 the default encryption algorithm such that the triple-DES 
algorithm is employed if TLCE's do not object to it. In 
the case where each TLCE arbitrarily determines the 
encryption algorithm or the key length, when sub-EKB's 
produced by different TLCE's are combined together in- 

25 to a single EKB, each (encrypted) key is rewritten into 
data with a predetermined length such as 16 bytes so 
that the resultant combined EKB can be used by any 
device managed by any TLCE. By properly determining 
the data format of the combined EKB used in common 

30 in a plurality of category trees, it becomes possible for 
any device in any category tree to correctly determine 
the location of the key data to be used. For example, if 
each key data in the EKB is represented in 1 6 bytes, the 
device can sequentially extract the correct key data that 

35 can be processed by the device, and can finally acquire 
the root key 

[0331] That is, in accordance with the data format of 
the combined EKB produced from a plurality of 
sub-EKB's, a plurality of key data are stored in fixed- 

40 length data fields. Therefore, when sub enabling key 
blocks (sub-EKB's) having different key data leagths ac- 
cording to different algorithms are combined into a sin- 
gle EKB, even if a plurality of encrypted key data of 
sub-EKB's are rearranged in accordance with the loca- 

45 tions of the nodes or leaves in the key tree, it is possible 
to correctly extract necessary key data in accordance 
with the lags described in the EKB. Such a combined 
EKB may be distributed to users (devices) by means of 
transmission via a network or by providing a storage me- 

50 dium on which the EKB is stored. 

[0332] The key distribution center (KDC) assembles 
or combines the sub-EKB's received from TLCE's as re- 
quired, and adds a version number and verification in- 
formation. The resultant completed EKB is transmitted 

55 to the EKB requester. A digital signature using the public 
key cryptography may be written by a certificate author- 
ity (CA) other than the key distribution center (KDC). 
[0333] The process of producing sub-EKB's and com- 
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bining them into a single EKB is described with refer- 
ence to Fig. 55. Fig. 55 shows a sub-EKB-(A), which is 
produced by a TLCE of a category tree A (51 00) in the 
process of producing a combined EKB that can be used 
in common by both category trees A (5100) and B 
(5200). The sub-EKB-(A) is produced such that each de- 
vice in the category tree A (5100) can extract the root 
key. Although in the previous examples, the root tree 
5300 has an 8-level tree structure, a 2-level tree struc- 
ture is assumed in the present example for the purpose 
of simplicity. 

[0334] In Fig. 55, each underlined 3-digit number 
[XXX] in the tree structure denotes a tag (e, I, r) in the 
EKB. As described earlier (Figs. 26 and 27), e = 1 de- 
notes that there is data, and e = 0 denotes that there is 
no data. 1 = 1 denotes that there is no branch extending 
to left, and I = 0 denotes that there is a branch extending 
to left, r = 1 denotes that there is no branch extending 
to right, and r = 0 denotes that there is a branch extend- 
ing to right. 

[0335] In order to produce the sub-EKB-(A) such that 
all devices (leaves) in the category tree A (51 00) shown 
in Fig. 55 can extract the root key the sub-EKB-(A) 
should include data produced by encrypting the root key 
using a node key held in common by all leaves. Each 
device has node keys in its path in the device node key 
(DNK) region 5120 of the category tree A (51 00) shown 
in Fig. 55. Therefore, if the root key is encrypted using 
a node key at the top in the DNK region 5120, then the 
resultant EKB satisfies the above requirement 
[0336] Thus, the TLCE of the category tree A (51 00) 
produces the sub-EKB-(A) such that its tag part consists 
of 101 , 010, 000, 111, and 111 , and its key part consists 
of Enc(K010, Kroot) and Enc(K011, Kroot). The TLCE 
of the category tree A. (5100) transmits the resultant 
sub-EKB-(A) to the key distribution center (KDC). 
[0337] A sub-EKB-(B) produced by the category tree 
B (5200) is described below with . reference to Fig. 56. 
In order to produce the sub-EKB-(B) such that all devic- 
es (leaves) in the category tree B (5200) can extract the 
root key, the sub-EKB-(B) should include data produced 
by encrypting the root key using a node key held in com- 
mon by all leaves. Each device has node keys in its path 
in the device node key (DNK) region 5220 of the cate- 
gory tree B (5200) shown in Fig. 56, Therefore, if the 
root key is encrypted using a node key at the top in the 
DNK region 5220, then the resultant EKB satisfies the 
above requirement. 

[0338] Thus, the TLCE of the category tree B (5200) 
produces the sub-EKB-(B) such that its tag part consists 
of 110, 010, 000, 111 , and 111 , and its key part consists 
of Enc(K11 0, Kroot) and Enc(K111 , Kroot). The TLCE of 
the category tree B (5200) transmits the resultant 
sub-EKB-(B) to the key distribution center (KDC). 
[0339] The key distribution center (KDC) produces a 
combined EKB from the sub-EKB-(A) and the 
sub-EKB-(B) produced by the respective TLCE's. The 
process of producing the combined EKB is described 



below with reference to Fig. 57. The combined EKB is 
produced such that all devices belonging to the category 
tree A (5100) and all devices belonging to the category 
tree B (5200) can extract the root key from the EKB. Ba- 

s sically, the combined EKB can be produced by combin- 
ing the sequences of key data of the received sub-EKB's 
into a single sequence of key data such that the loca- 
tions of key data in the sequence correspond to the lo- 
cations in the tree from top to bottom and from left to 

10 right. 

[0340] Thus, the tag part of the combined EKB be- 
comes 100, 010, 010 ; 000, 000, 111, 111, 111, 111, and 
the key part becomes Enc(K010, Kroot), Enc(K011, 
Kroot), Enc(K110, Kroot), Enc(K111 , Kroot). If each key 
15 data in the key part is represented by for example, 16 
bytes, as described above, then each device in the cat- 
egory trees can detect the locations of the key data that 
can be processed by the device, and thus can extract 
the root key from the combined EKB. 
20 [0341] In the aboveexample of the process of produc- 
ingthe sub-EKB's and the combined EKB, it is assumed 
that any category tree does not include a revoked de- 
vice. The process of producing sub-EKB's and a com- 
bined EKB is described below for the case where there 
25 is a revoked device. 

[0342] Fig. 58 shows the process of producing a 
sub-EKB when the category tree A (5100) includes a 
revoked device (01 1 01 ) 51 50. In this case, the sub-EKB 
is produced as a sub- EKB- (A') that cannot be processed 
30 by the revoked device (01101) 5150 but can be by the 
other devices in the category tree A (5100). 
[0343] In this specific example, the sub-EKB is pro- 
duced by selecting key data along the paths denoted by 
bold lines in Fig. 58. Thus, the sub-EKB-(A') produced 
35 by the TLCE of the category tree A (5100) includes a 
tag part consisting of 1 01 , 01 0, 000, 1 1 1 , 000, 001 , 1 1 1 , 
and 111, and a key part consisting of Enc(K010, Kroot), 
Enc(K01 1 1 , Kroot), and Enc(K01 1 00, Kroot). The TLCE 
of the category tree A (5100) transmits the resultant 
40 sub-EKB-(A') to the key distribution center (KDC). 

[0344] The key distribution center (KDC) produces a 
combined EKB from the sub-EKB-(A') and a 
sub-EKB-(B) received from the TLCE of the category 
tree B (5200) (Fig. 56). The process of producing the 
45 combined EKB is described below with reference to Fig. 
59. The combined EKB is produced such that all devices 
belonging to the category tree A (5100) except for the 
revoked device (01 1 01 ) 51 50 and all devices belonging 
to the category tree B (5200) without exception can ex- 
50 tract the root key from the EKB. Basically, the combined 
EKB can be produced by combining the sequences of 
key data of the received sub-EKB's into a single se- 
quence of key data such that the locations of key data 
in the sequence correspond to the locations in the tree 
55 from top to bottom and from left to right. 

[0345] Thus, the tag part of the combined EKB consist 
of 100, 010, 010, 000, 000, 111 , 000, 111 , 111 , 001 , 111 , 
and 1 11 , and the key part consists of Enc(K01 0, Kroot), 
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Ene(K110, Kroot), Enc{K111 , Kroot), Enc(K0111 , Kroot), 
and Enc(K011 00, Kroot). This combined EKB allows ex- 
traction of the root key, for all devices belonging to the 
category tree A (51 00) except for the revoked device 
(01101) 51 50 and for all devices belong to the category 
tree B (5200) without exception. 

(5) Use of EKB 

[0346] The EKB produced by the key distribution cent- 
er (KDC) via the process described above is transmitted 
to the EKB requester. 

[0347] For example, in the case where the EKB re- 
quester is 

[a] a content provider (CP) that provides a content- 
stored medium such as a CD or DVD, or 

[b] a content provider that provides electronic con- 
tent distribution (ECD) service, a content key is en- 
crypted using the root key that can be extracted 
from the EKB, and a content is encrypted using the 
content key and distributed. The resultant content 
can be used only by authorized devices which be- 
long to the specific category and thus can process 
the EKB. 

[0348] On the other hand, when the EKB requester is 

[c1] a format holder that provides an acquired EKB 
to a manufacturers of a storage medium according 
to a format in which the EKB is stored into the stor- 
age medium when it is produced, 

the produced EKB and the content key encrypted using 
the root key are provided to the storage medium manu- 
facturer, and storage media on which the EKB and the 
content key encrypted using the root key are stored are 
produced by the storage medium manufacturer or the 
EKB requester itself, and the produced storage media 
are distributed. In this case, only the devices which be- 
long to the specific category tree and thus can process 
the EKB can perform encryption and decryption using 
the EKB stored on the storage medium in the operation 
recording/reproducing the content. 
[0349] In the case where the EKB requester is 

[c2] a format holder that provides an acquired EKB 
to a manufacturers of a recording device according 
to a format in which the EKB is stored into the re- 
cording device when it is produced, 

the produced EKB and the content key encrypted using 
the root key are provided to the recording device man- 
ufacturer, and recording devices in which the EKB and 
the content key encrypted using the root key are stored 
are produced by the recording device manufacturer or 
the EKB requester itself, and the produced recording de- 
vices are distributed. In this case, only the devices which 



belong to the specific category tree and thus can proc- 
ess the EKB can perform encryption and decryption us- 
ing the EKB in the operation of recording/reproducing 
the content. 

5 [0350] In the above process, mutual authentication 
and encryption of transmission data are performed, as 
required, in communication between entities, EKB re- 
questers, the key distribution center (KDC), andTLCE's. 
Furthermore, encryption of other messages, writing of 

10 signature, and data verification may also be performed. 
In a case where authentication or cryptographic com- 
munication is performed using the public key crypto- 
graphic technology, it is required that entities already 
have their public keys. (Producing an EKB by simply 

15 combining sub-EKB's) 

[0351] In the above-described process of producing 
a combined EKB from sub-EKB's, a sequence of en- 
crypted key data included in the respective sub-EKB's 
are rearranged such that the locations of key data in the 

20 sequence correspond to the locations in the whole tree 
from top to bottom. A technique of producing a com- 
bined EKB by simply combining sub-EKB's produced by 
TLCE's of category trees into a single EKB without per- 
forming rearrangement is described below. 

25 [0352] Fig. 60 shows an example of a combined EKB 
6000 produced by simply combining sub-EKB's pro- 
duced by TLCE's of category trees into a single EKB 
without performing rearrangement. 
[0353] In the process of issuing an EKB, the key dis- 

30 tribution center (KDC) sends a sub-EKB production re- 
quest to TLCE's which are entities managing category 
trees corresponding to an EKB type identification 
number, in the EKB type definition list, specified by an 
EKB requester. Sub-EKB's 6110, 6120 and so on re- 

35 ceived from TLCE's are simply combined together into 
a single EKB thereby producing a combined EKB. In or- 
der that each device belonging to a specific category 
can select, from the combined EKB, a sub-EKB which 
corresponds to the specific category the device belongs 

40 to and thus which can be processed by the device, data 
(data length) 6111 indicating the data size of each 
sub-EKB and data (node ID) 6112 indicating the cate- 
gory corresponding to each sub-EKB are added. 
[0354] That is, the combined EKB includes, in addition 

45 to the selected sub-EKB's, the data indicating the data 
length of respective sub-EKB storage areas and the 
node ID'S, serving as sub-EKB identification data, of the 
respective category trees corresponding to the 
sub-EKB's. Furthermore, information indicating the 

50 number of sub-EKB's included in the combined EKB is 
described in the header 6200. Still furthermore, a signa- 
ture 6300 is produced (by a certificate authority or the 
like) in accordance with the whole data of the combined 
EKB and added thereto. 

55 [0355] Fig. 61 shows a combined EKB produced in 
the manner described above with reference to Fig. 57. 
A sub-EKB described in a sub-EKB field 61 1 0 is exactly 
the same as the sub-EKB-(A) produced by the TLCE of 
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the category tree A described above with reference to 
Fig. 55, wherein the tag part thereof consists of 101, 
010, 000, 111, and 111, and the key part consists of Enc 
(K010, Kroot) and Enc(K011 r Kroot). A sub-EKB de- 
scribed in a sub-EKB field 6120 is exactly the same as 
the sub-EKB-(B) produced by the TLGE of the category 
tree B described above with reference to Fig. 56, where- 
in the tag part thereof consists of 110, 010, 000, 111, 
and 111, and the key part consists of Enc(K1 1 0, Kroot) 
and Enc(K1 11, Kroot). 

[0356] Fig. 62 shows the data structure of a combined 
EKB produced from sub-EKB's, shown in Figs. 58 and 
59, produced in a situation in which there is a revoked 
device. A sub-EKB described in a sub-EKB field 6 1 1 0 is 
exactly the same as sub-EKB-(A') produced by the 
TLCE of the category tree A described above with ref- 
erence to Fig. 58, wherein the tag part therGof consists 
of 101, 010, 000, 111, 000, 001, 111, and 111, and the 
key part consists of Enc(K010, Kroot), Enc(K0111, 
Kroot), and Enc(K01100, Kroot). A sub-EKB described 
in a sub-EKB field 6120 is exactly the same as 
sub-EKB-(B) produced by the TLCE of the category tree 
B, including no revoked device, described above with 
reference to Fig. 56, wherein the tag part thereof con- 
sists of 110, 010, 000, 111, and 111, and the key part 
consists of Enc(K110, Kroot) and Enc(K111 : Kroot). 
[0357] The combined EKB described above makes it 
possible for each device belonging to a specific category 
to select a sub-EKB corresponding to that specific cat- 
egory and process (decrypt) the selected sub-EKB. This 
allows a sub-EKB to be produced for each category 
(TLCE) using an absolutely arbitrary cryptographic al- 
gorithm or key length. In other words, each TLCE can 
determine the cryptographic algorithm and the key 
length without being influenced by the other categories. 
[0358] The key distribution center (KDC) does not 
need to deassemble and reassemble the tag parts and 
the key data parts of sub-EKB's received from respec- 
tive TLCE's, and thus the complexity of the process is 
eased. 

[0359] When a device acquires an EKB produced ac- 
cording to the present scheme, the device can detect a 
sub-EKB corresponding to a category to which the de- 
vice belongs, and can extract a root key by processing 
the sub-EKB in accordance with a specific procedure 
determined by a TLCE managing the device. It is not 
needed to know the procedures determined by the 
TLCE's of the other categories. It is also not needed to 
describe keys in a sub-EKB such that the keys have a 
fixed length, and, theoretically, the key length may be 
set to any arbitrary value. 

(Revocation (1)) 

[0360] A revocation process performed in a case 
where an EKB usable in common by a plurality of cate- 
gories is described below. First, a revocation process is 
described which may occur in a situation in which an 



. encrypted content is acquired from the outside via a net- 
work or a medium, a content key is decrypted using a 
key extracted from an EKB, and finally the content is 
decrypted. 

5 [0361] Referring to Fig. 63, an EKB 7000 is assumed 
to be used in common by a category tree A (7100) and 
a category tree B (7200). The EKB 7000 used in com- 
mon by the category tree A (71 00) and the category tree 
B (7200) is assigned an EKB type identification number 

10 #1 jn the EKB type definition list. 

[0362] In such a situation, a content provider provides 
a content encrypted using a content key via a network 
or a medium, and devices belong to a category tree A 
(7100) and devices belonging to a category tree B 

15 (7200) use the content by extracting a root key from the 
EKB 7000, acquiring the content key by performing de- 
cryption using the root key, and finally decrypting the en- 
crypted content using the content key. 
[0363] In this situation, if breakage of secrecy of key 

20 data or another unauthorized state of a device A1 (71 20) 
belonging to the category tree A (71 00) is detected, the 
device A1 (7120) is revoked. 

[0364] To perform revocation, the TLCE of the cate- 
gory tree A (71 00) first issues a tree change notification 

25 (Fig. 53) to the key distribution center (KDC). In accord- 
ance with the received tree change notification, the key 
distribution center (KDC) sends a notification to TLCE's 
and EKB requesters managed by the key distribution 
center (KDC). The notification includes only information 

30 indicating that the tree change notification has been re- 
ceived, and renewal of the EKB type definition list is not 
performed at this point of time. 

[0365] The tree change notification issued in re- 
sponse to revocation may be sent only to entities of EKB 

35 requesters using the EKB that can be processed by the 
category tree in which revocation occurs, or further to 
category entities that manage other category trees us- 
ing the same EKB as that used by the category tree in 
which revocation occurs. In order to make it possible to 

40 perform the above process, the key distribution center 
(KDC) holds a list of users of already-issued EKB's, in 
which EKB requesters using specific EKB types and cor- 
responding EKB type identification numbers are listed. 
[0366] A content provider, which provides a content 

45 to devices in the category tree in which revocation has 
been performed and which is also an EKB requester in 
this situation, requests the key distribution center (KDC) 
to produce an EKB renewed such that only devices oth- 
erthan the revoked device can process the EKB. In this 

50 specific case, the content provider behaving as the EKB 
requester in such a situation specifies the EKB type 
identification number #1 indicating the EKB type that is 
used in common by the category tree A (7100) and the 
category tree B (7200). Thereafter, the EKB requester 

55 produces a new root key and sends it to the KDC, or 
alternatively the EKB requester requests the KDC to 
produce a new root key. 

[0367] In accordance with the specified EKB type 
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identification number #1, the key distribution center 
(KDC) searches the EKB type definition list to detect 
nodes of relating category trees and requests TLCE's 
of category trees A (71 00) and B (7200) corresponding 
to the detected nodes to produce a sub- EKB from which 
authorized devices can extract a new root key. 
[0368] In response to the request, each of TLCE's of 
the category trees A (7100) and B (7200) produces a 
sub-EKB. In this specific case, in the category tree A 
(71 00), a sub-EKB-(A) is produced such that only devic- 
es other than the revoked device A1 (71 20) can extract 
anew root key from the sub- EKB- (A). In the category 
tree B (7200), if there is no revoked device, a 
sub-EKB-(B) is produced such that all devices belong- 
ing to the category B (7200) can extract a new root key 
from the sub-EKB-(B) and the resultant sub-EKB-(B) is 
transmitted to the key distribution center (KDC). 
[0369] The key distribution center (KDC) produces a 
combined EKB from the sub-EKB's received from the 
respective TLCE's in the above-described manner, and 
transmits the resultant EKB to the EKB requester (con- 
tent provider). 

[0370] The EKB requester (content provider) distrib- 
utes a content using the new EKB received from the key 
distribution center (KDC). More specifically, the EKB re- 
quester (content provider) encrypts the content using a 
content key and encrypts the content key using the root 
key extracted by decrypting the EKB, and distributes the 
encrypted content and content key. The devices belong- 
ing to the category tree A (7100) and the devices be- 
longing to the category tree B (7200) can usethecontent 
by extracting the root key from the EKB, extracting the 
content key by performing decryption using the root key, 
and finally decrypting the encrypted content using the 
content key. However, the revoked device A1 (7120) in 
the category tree A (71 00) cannot process the renewed 
EKB and thus cannot use the content. 
[0371] In the example described above, the key dis- 
tribution center (KDC) does not renew the EKB type def- 
inition list at the point of time at which the tree change 
notification is received from the TLCE, Alternatively, at 
the point of time at which the tree change notification is 
received, the key distribution center (KDC) may renew 
the EKB and the EKB type definition list in accordance 
with the tree change notification, and may transmit the 
renewed EKB type definition list to the EKB requesters 
and TLCE's. 

(Revocation (2)) 

[0372] A revocation process is now described which 
may occur in a situation in which various contents are 
encrypted and stored by a user into a recording device 
or a storage medium in which an EKB is stored, wherein 
a root key extracted from the EKB stored in the recording 
device or the storage medium is used as a key needed 
in encryption and decryption. This type of recording de- 
vice or storage medium is said to be of a self-recording 



type. 

[0373] Referring to Fig. 64, an EKB 8000 is assumed 
to be used in common by a category tree A (81 00) and 
a category tree B (8200). That is, the EKB for common 

5 use is stored in recording devices or the storage media 
used in common in the category tree A (81 00) and the 
category tree B (8200), and users record and play back 
a content by means of encryption and decryption using 
the EKB. The EKB 8000 used in common by the cate- 

10 gory tree A (81 00) and the category tree B (8200) is as- 
signed an EKB type identification number #1 in the EKB 
type definition list. 

[0374] In this situation, if breakage of secrecy of key 
data or another unauthorized state of a device A1 (81 20) 
15 belonging to the category tree A (81 00) is detected, the 
device A1 (8120) is revoked. 

[0375] To perform revocation, the TLCE of the cate- 
gory tree A (81 00) first issues a tree change notification 
(Fig. 53) to the key distribution center (KDC). In accord- 

20 ance with the received tree change notification, the key 
distribution center (KDC) sends a notification to TLCE's 
managed by the key distribution center (KDC) and to 
associated EKB requesters. The notification includes 
only information indicating that the tree change notifica- 

25 tion has been received, and renewal of the EKB type 
definition list is not performed at this point of time. 
[0376] In order to prevent contents from being further 
used by the revoked device A1 (8120), the TLCE of the 
category tree in which revocation has occurred requests 

30 the key distribution center (KDC) to produce an EKB re- 
newed such that only devices other than the revoked 
device can process the EKB. In this situation, this TLCE 
behaves as an EKB requester. In this specific case, the 
TLCE behaving as the EKB requester in such a situation 

35 specifies the EKB type identification number #1 indicat- 
ing the EKB type that is used in common by the category 
tree A (81 00) and the category tree B (8200). Thereafter, 
the EKB requester produces a new root key and sends 
it to the KDC, or alternatively, the EKB requester re- 

40 quests the KDC to produce a new root key. 

[0377] In accordance with the specified EKB type 
identification number #1 , the key distribution center 
(KDC) searches the EKB type definition list to detect 
nodes of relating category trees and requests TLCE's 

45 of category trees A (81 00) and B (8200) corresponding 
to the detected nodes to produce a sub-EKB from which 
authorized devices can extract a new root key. 
[0378] In response to the request, each of TLCE's of 
the category trees A (8100) and B (8200) produces a 

50 sub-EKB. In this specific case, in the category tree A 
(8100), asub-EKB-(A) is produced such that only devic- 
es other than the revoked device A1 (8120) can extract 
a new root key from the sub-EKB-(A). In the category 
tree B (8200), if there is no revoked device, a 

55 sub-EKB-(B) is produced such that all devices belong- 
ing to the category B (8200) can extract a new root key 
. from the sub-EKB-(B), and the resultant sub-EKB-(B) is 
transmitted to the key distribution center (KDC). 
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[0379] The key distribution center (KDC) produces a 
combined EKB from the sub-EKB's received from the 
respective TLCE's in the above-described manner, and 
transmits the resultant EKB to the respective TLCE's 
(format holders). 

[0380] Each TLCE (format holder) sends the new 
EKB received from the key distribution center (KDC) to 
devices to update the EKB stored in the devices. The 
devices belonging to the category tree A (8100) and the 
devices belonging to the category tree B (8200) can 
record a new content into the devices using, in the en- 
cryption/decryption process, the root key extracted from 
the updated EKB. The recorded content encrypted us- 
ing the new EKB can be decrypted only when the cor- 
responding EKB is applied, and thus the revoked device 
cannot use the content. 

[0381] The present invention has been described in 
detail above with reference to particular embodiments. 
It will be apparent to those skilled in the art that various 
modifications and substitution to those embodiments 
may be made in the embodiment chosen for illustration 
without departing from the spirit and scope of the inven- 
tion. That is, the embodiments have been described 
above by way of example and not limitation. The scope 
of the invention is to be determined solely by the ap- 
pended claims. 

Industrial Applicability 

[0382] In the information processing system accord- 
ing to the present invention, as described above, a key 
tree is produces so as to include a plurality of subtrees 
serving as category trees that are grouped in accord- 
ance with categories and managed by category entities; 
and an enabling key block (EKB) is produced so as in- 
clude data produced by selecting a path in the key tree 
and encrypting an upper-level key in the selected path 
using a lower-level key in the selected path and the re- 
sultant enabling key block (EKB) is providedto a device, 
wherein issuing of EKB's is managed on the basis of the 
an EKB type definition list representing the correspond- 
ence between an EKB type identifier and one or more 
identification data identifying one or mo re category trees 
that can process an EKB of an EKB type identified by 
the EKB type identifier, thereby making it possiblefor an 
EKB requester, which issues an EKB production re- 
quest, to easily select a category to which the EKB is to 
be applied. 

[0383] Furthermore, in the information processing 
system and method according to the present invention, 
registration and revocation of an EKB type identifier in 
the EKB type definition list are performed under the 
management of the key distribution center (KDC) such 
that registration and revocation are performed only 
when a predetermined condition such as that as to ap- 
proval or request of an entity managing a category tree 
is satisfied, thereby ensuring reliability of information 
registered in the EKB type definition list. 



[0384] Furthermore, in the information processing 
system and method according to the present invention, 
the EKB type definition list is provided in response to a 
request from an EKB request or an entity managing a 
5 category tree so that the EKB requester and the cate- 
gory entity can obtain a newest version of EKB type def- 
inition list. 

[0385] Furthermore, in the information processing 
system and method according to the present invention, 

10 when a change occurs in the EKB type definition list, the 
EKB requester and the entity managing the category 
tree are informed of the change thereby ensuring that 
the EKB requester and the entity managing the category 
tree can properly perform their operation on the basis of 

15 newest version of EKB type definition list. 



Claims 

20 1. An information processing system in which a key 
tree is formed so as to include leaves, a root, and 
nodes existing in paths from the respective leaves 
to the root wherein a plurality of devices are as- 
signed to respective leaves and keys are assigned 

25 to the root, the leaves, and the nodes, respectively; 
and an enabling key block (EKB) is provided to a 
device, wherein the enabling key block (EKB) in- 
cludes data produced by selecting a path in the key 
tree and encrypting an upper-level key in the select- 
so ed path using a lower-level key in the selected path 
such that the encrypted data can be decrypted only 
by the device which can use a node key set corre- 
sponding to the selected path, 

wherein the key tree includes a plurality of 

35 subtrees serving as category trees that are grouped 
in accordance with categories and managed by cat- 
egory entities; and 

the enabling key block (EKB) is produced by 
a key distribution center (KDC) such that an EKB 

40 type definition list representing the correspondence 
between an EKB type identifier and one or more cat- 
egory tree identification data each identifying a cat- 
egory tree that can process an EKB of an EKB type 
identified by the EKB type identifier is held in the 

45 key distribution center (KDC), one or more category 
tree identification data corresponding to an EKB 
type identifier included in an EKB request are ex- 
tracted from the EKB type definition list, and an EKB 
is produced which can be decrypted in common in 

so the one or more category trees identified by the ex- 
tracted one or more category tree identification da- 
ta. 

2. An information processing system according to 
55 Claim 1 , wherein, in the EKB type definition list, the 
identification data identifying a category tree that 
can process an EKB is a node ID identifying a node 
in the category tree. 
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7. An information processing system according to 
Claim 1 , wherein the key distribution center (KDC) 
performs registration of a new EKB type identifier in 
the EKB type definition list, if and only if approval of 
5 the registration is obtained from all category entities 
managing one or more category trees selected as 
category trees that can process an EKB type to be 
registered. 

10 8. An information processing system according to 
Claim 1 , wherein the key distribution center (KDC) 
performs revocation of a EKB type identifier regis- 
tered in the EKB type definition list, if and only if a 
revocation request is received from at least one of 

*5 category entities managing one or more category 
trees selected as category trees that can process 
an EKB type to be revoked. 

9. An information processing system according to 
20 Claim 1 , wherein in response to an EKB type defi- 
nition list request issued by an EKB requester or a 
category entity requesting the key distribution cent- 
er (KDC) to produce an EKB, the key distribution 
center (KDC) transmits a newest version of EKB 

25 type definition list to the requester of the list. 

10. An. information processing system according to 
Claim 1 , wherein the category entity sends informa- 
tion of a change in a category tree managed by the 

30 category entity to the key distribution center (KDC); 
and 

in accordance with the tree change notifica- 
tion received from the category entity, the key dis- 
tribution center (KDC) performs necessary renewal 
35 on the EKB type definition list and sends renewal 

information to the EKB requester and the category 
entity. 



3. An information processing system according to 
Claim 1, wherein the EKB type definition list in- 
cludes a description of a device belonging to a cat- 
egory tree. 

4. An information processing system according to 
Claim 1 , wherein the EKB type definition list can by 
held or accessed by an EKB requester that requests 
the key distribution center (KDC) to produce an 
EKB; and 

the EKB requester selects an EKB type iden- 
tifier on the basis of the EKB type definition list and 
outputs an EKB production request including the 
selected EKB type identifier to the key distribution 
center (KDC). 

5. An information processing system according to 
Claim 1 , wherein the category entity produces a sub 
enabling key block (sub-EKB) serving as an EKB 
that can be processed on the basis of one or more 
keys assigned to nodes or leaves in a category tree 
managed by the category entity; and 

on the basis of one or more sub-EKB's pro- 
duced by one or more category entities correspond- 
ing to one or more category tree identification data 
selected on the basis of the EKB type definition list, 
the key distribution center (KDC) produces an EKB 
that can be processed in common in one or catego- 
ry trees defined in the EKB type definition lists. 

6. An information processing system according to 
Claim 1 , wherein the key tree includes a root tree 
having a multilevel tree structure at the top, a top- 
level category tree directly connected to the root 
tree, and a subcategory tree located at a level be- 
low the top-level category tree and connected to the 
top-level category tree; 

the category entity serves as a manager entity 
of the top-level category tree and manages the top- 
level category tree and the sub-category tree locat- 
ed below the top level category tree and connected 
to the top level category tree; 

the category entity produces a sub enabling 
key bock (sub-EKB) serving as an EKB that can be 
processed on the basis of one or more keys as- 
signed to nodes or leaves in the top-level category 
tree and sub-category tree ( located below the top- 
level category tree and connected to the top-level 
category tree, which are managed by the category 
entity: and 

on the basis of one or more sub-EKB's pro- 
duced by one or more category entities correspond- 
ing to one or more category tree identification data 
selected on the basis of the EKB type definition list, 
the key distribution center (KDC) produces an EKB 
that can be processed in common in one or catego- 
ry trees defined in the EKB type definition lists. 



11. An EKB distribution apparatus serving to produce 

40 an EKB and being disposed in an information 

processing system in which a key tree is formed so 
as to include a subtree serving as a category tree 
categorized in accordance with a category, the cat- 
egory tree including leaves, a root, and nodes -ex- 

45 isting in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to re- 
spective leaves and keys are assigned to the root, 
the leaves, and the nodes, respectively; and an en- 
abling key block (EKB) is provided to a device, 

50 wherein the enabling key block (EKB) includes data 
produced by selecting a path in the key tree and 
encrypting an upper-level key in the selected path 
using a lower-level key in the selected path such 
that the encrypted data can be decrypted only by 

55 the device which can use. a node key set corre- 
sponding to the selected path, 

wherein the EKB distribution apparatus 
stores, in storage means, an EKB type definition list 
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representing the correspondence between an EKB 
type identifier and one or more identification data 
identifying one or more category trees that can 
process an EKB of an EKB type identified by the 
EKB type identifier; and 

upon receiving an EKB production request 
from an EKB requester, extracts one or more cate- 
gory tree identification data corresponding to an 
EKB type identifier included in the EKB production 
request from the EKB type definition list, and pro- 
duces an EKB that can be decrypted in common in 
one or more category trees identified by the one or 
more category tree identification data. 

12. An EKB requesting apparatus serving as an EKB 
requester which issues an EKB production request 
and being disposed in an information processing 
system in which a key tree is formed so as to include 
a subtree serving as a category tree categorized in 
accordance with a category, the category tree in- 
cluding leaves, a root, and nodes existing in paths 
from the respective leaves to the root, wherein a 
plurality of devices are assigned to respective 
leaves and keys are assigned to the root, the 
leaves, and the nodes, respectively; and an ena- 
bling key block (EKB) is provided to a device, 
wherein the enabling key block (EKB) includes data 
produced by selecting a path in the key tree and 
encrypting an upper-level key in the selected path 
using a lower-level key in the selected path such 
that the encrypted data can be decrypted only by 
the device which can use a node key set corre- 
sponding to the selected path, 

wherein the EKB requesting apparatus 
stores, in storage means, an EKB type defini- 
tion list representing the correspondence between 
an EKB type identifier and one or more identification 
data identifying one or more category trees that can 
process an EKB of an EKB type identified by the 
EKB type identifier; and 

produces EKB production request data in- 
cluding an EKB type identifier in the EKB type def- 
inition list and outputs the EKB issue request. 

13. A category tree managing apparatus serving to 
manage a category tree and being disposed in an 
information processing system in which a key tree 
is formed so as to include a subtree serving as a 
category tree categorized in accordance with a cat- 
egory, the category tree including leaves, a root, 
and nodes existing in paths from the respective 
leaves to the root, wherein a plurality of devices are 
assigned to respective leaves and keys are as- 
signed to the root, the leaves, and the nodes, re- 
spectively; and an enabling key block (EKB) is pro- 
vided to a device, wherein the enabling key block 
(EKB) includes data produced by selecting a path 
in the key tree and encrypting an upper-level key in 



the selected path using a lower-level key in the se- 
lected path such that the encrypted data can be de- 
crypted only by the device which can use a node 
key set corresponding to the selected path, 

s wherein the category tree managing appara- 

tus produces a sub enabling key block (sub-EKB) 
functioning as an EKB that can be processed on the 
basis of a key assigned to a node or leaf belonging 
to a category tree managed by the category tree 

10 managing apparatus and outputs the resultant sub 
enabling key block (sub-EKB) to a key distribution 
center (KDC). 

14. An information storage medium having an EKBtype 
15 definition list stored therein, the EKB type definition 

list being produced such that a key tree is formed 
so as to include a subtree serving as a category tree 
categorized in accordance with a category, the cat- 
egory tree including leaves, a root, and nodes ex- 

20 isting in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to re- 
spective leaves and keys are assigned to the root, 
the leaves, andthe nodes, respectively; an enabling 
key block (EKB) js produced so as to include data 

25 produced by selecting a path in the key tree and 
encrypting an upper-level key in the selected path 
using a lower-level key in the selected path so that 
the encrypted data can be decrypted only by the de- 
vice which can use a node key set corresponding 

30 to the selected path; and the EKBtype definition list 
is produced so as to represent the correspondence 
between an EKB type identifier assigned to the en- 
abling key block (EKB) and identification data iden- 
tifying a category tree that can process an EKB of 

35 an EKB type identified by the EKB type identifier. 

15. An information storage medium according to Claim 
14, wherein, in the EKBtype definition list, the iden- 
tification data identifying a category tree that can 

40 process an EKB is a node ID identifying a node in 

the category tree. 

16. An inf ormation storage medium according to Claim 
14, wherein the EKB type definition list includes a 

45 description of a device belonging to a category tree. 

17. An information processing method comprising: 



50 



55 



forming a key tree including a subtree serving 
as a category tree categorized in accordance 
with a category and managed by a category en- 
tity, said category tree including leaves, a root, 
and nodes existing in paths from the respective 
leaves to the root, wherein a plurality of devices 
are assigned to respective leaves and keys are 
assigned to the root, the leaves, and the nodes, 
respectively; and providing an enabling key 
block (EKB) to a device, wherein the enabling 
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key block (EKB) includes data produced by se- 
lecting a path in the key tree and encrypting an 
upper-level key in the selected path using a 
lower-level key in the selected path such that 
the encrypted data can be decrypted only by 
the device which can use a node key set corre- 
sponding to the selected path, 

wherein the enabling key block (EKB) is pro- 
duced by a key distribution center (KDC) such that 
an EKB type definition list representing the corre- 
spondence between an EKB type identifier and one 
or more category tree identification data each iden- 
tifying a category tree that can process an EKB of 
an EKB type identified by the EKB type identifier is 
held in the key distribution center (KDC), one or 
more category tree identification data correspond- 
ing to an EKB type identifier included in an EKB re- 
quest are extracted from the EKB type definition list, 
and an EKB is produced which can be decrypted in 
common in the one or more category trees identified 
by the extracted one or more category tree identifi- 
cation data. 

18. An information processing method according to 
Claim 1 7, wherein in the EKB type definition list, the 
identification data identifying a category tree that 
can process an EKB is a node ID identifying a node 
in the category tree. 

19. An information processing method according to 
Claim 17, wherein the EKB type definition list in- 
cludes a description of a device belonging to a cat- 
egory tree. 

20. An information processing method according to 
Claim 17, wherein the EKB type definition list can 
by held or accessed by an EKB requester that re- 
quests the key distribution center (KDC) to produce 
an EKB; and 

the EKB requester selects an EKB type iden- 
tifier on the basis of the EKB type definition list and 
outputs an EKB production request including the 
selected EKB type identifier to the key distribution 
center (KDC). 

21. An information processing method according to 
Claim 17, wherein the category entity produces a 
sub enabling key block (sub-EKB) serving as an 
EKB that can be processed on the basis of one or 
more keys assigned to nodes or leaves in a cate- 
gory tree managed by the category entity; and 

on the basis of one or more sub-EKB's pro- 
duced by one or more category entities correspond- 
ing to one or more category tree identification data 
selected on the basis of the EKB type definition list, 
the key distribution center (KDC) produces an EKB 
that can be processed in common in one or catego- 



ry trees defined in the EKB type definition lists. 

22. An information processing method according to 
Claim 17, wherein the key tree includes a root tree 
having a multilevel tree structure at the top, a top- 
level category tree directly connected to the root 
tree, and a sub-category tree located at a level be- 
low the top-level category tree and connected to the 
top-level category tree; 

the category entity serves as a manager entity 
of the top-level category tree and manages the top- 
level category tree and the sub-category tree locat- 
ed below the top level Category tree and connected 
to the top level category tree; 

the category entity produces a sub enabling 
key bock (sub-EKB) serving as an EKB that can be 
processed on the basis of one or more keys as- 
signed to nodes or leaves in the top-level category 
tree and sub-category tree, located below the top- 
level category tree and connected to the top-level 
category tree, which are managed by the category 
entity; and 

on the basis of one or more sub-EKB's pro- 
duced by one or more category entities correspond- 
ing to one or more category tree identification data 
selected on the basis of the EKB type definition list, 
the key distribution center (KDC) produces an EKB 
that can be processed in common in one or catego- 
ry trees defined in the EKB type definition lists. 

23. An information processing method according to 
Claim 1 7, wherein the key distribution center (KDC) 
performs registration of a new EKB type identifier in 
the EKB type definition list, if and only if approval of 
the registration is obtained from all category entities 
managing one or more category trees selected as 
category trees that can process an EKB type to be 
registered. 

An information processing method according to 
Claim 1 7, wherein the key distribution center (KDC) 
performs revocation of an EKB type identifier regis- 
tered in the EKB type definition list, if and only if a 
revocation request is received from at least one of 
category entities managing one or more category 
trees selected as category trees that can process 
an EKB type to be revoked. 

25. An information processing method according to 
50 Claim 1 7, wherein in response to an EKB type def- 
inition list request issued by an EKB requester or a 
category entity requesting the key distribution cent- 
er (KDC) to produce an EKB, the key distribution 
center (KDC) transmits a newest version of EKB 

55 type definition list to the requester of the list. 

26. An information processing method according to 
Claim 1 7, wherein the category entity sends infor- 
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mation of a change in a category tree managed by 
the category entity to the key distribution center 
(KDC); and 

in accordance with the tree change notifica- 
tion received from the category entity, the key dis- 5 
tribuLion center (KDC) performs necessary renewal 
on the EKB type definition list and sends renewal 
information to the EKB requester and the category 
entity. 

10 

27. A program storage medium having a computer pro- 
gram stored therein for causing a computer system 
to execute information processing in an information 
processing system in which a key tree is formed so 
as to include a subtree serving as a category tree i* 
categorized in accordance with a category, the cat- 
egory tree including leaves, a root, and nodes ex- 
isting in paths from the respective leaves to the root, 
wherein a plurality of devices are assigned to re- 
spective leaves and keys are assigned to the root, 20 
the leaves, and the nodes, respectively; and an en- 
abling key block (EKB) is provided to a device, 
wherein the enabling key block (EKB) includes data 
produced by selecting a path in the key tree and 
encrypting an upper-level key in the selected path 25 
using a lower- ievel key in the selected path such 
that the encrypted data can be decrypted only by 
the device which can use a node key set corre- 
sponding to the selected path, wherein the compu- 
ter program comprising the steps of: 30 

on the basis of an EKB type identifier included 
in an EKB production request, extracting iden- 
tification data identifying a category tree from 
an EKB type definition list representing the cor- 55 
respondence between an EKB type identifier 
and one or more identification data identifying 
one or more category trees that can process an 
EKB of an EKB type identified by the EKB type 
identifier; and 40 
producing an EKB that can be decrypted in 
common in one or more category trees identi- 
fied by the extracted identification data. 
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FIG. 4A 



EKB (ENABLE KEY BLOCK): EXAMPLE 1 

NODE KEYS OF VERSION OF t ARE 
TRANSMITTED TO DEVICES 0, 1, AND 2 



VERSION: t 


INDEX 


ENCRYPTION KEY 


0 


Enc(K(t)0, K(t)R) 


00 


Enc(K(t)00, K(t)0) 


000 


Enc(K000, K(t)00) 


001 . 


Enc(K(t)001, K(t)OO) 


0010 


Enc(K0O10, K(t)001) 
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